Repository: kedacore/keda-docs Branch: main Commit: 7d8e45a05df4 Files: 2089 Total size: 10.8 MB Directory structure: gitextract_gwzsnkkw/ ├── .devcontainer/ │ └── devcontainer.json ├── .editorconfig ├── .gitattributes ├── .github/ │ ├── CODEOWNERS │ ├── PULL_REQUEST_TEMPLATE.md │ ├── renovate.json5 │ ├── reviewers.yml │ └── workflows/ │ ├── auto-assign.yml │ ├── check-links.yml │ ├── pr-bot-welcome.yml │ └── stale.yml ├── .gitignore ├── .htmltest.yml ├── .nvmrc ├── .whitesource ├── CONTRIBUTING.md ├── LICENSE ├── MAINTAINERS.md ├── Makefile ├── README.md ├── archetypes/ │ ├── blog.md │ ├── provider.md │ ├── scaler.md │ └── troubleshooting.md ├── assets/ │ ├── js/ │ │ ├── alpine.js │ │ ├── docsearch.js │ │ ├── scaler-search.js │ │ └── site.js │ └── sass/ │ ├── card.sass │ ├── content.sass │ ├── nav.sass │ └── style.sass ├── content/ │ ├── blog/ │ │ ├── 2020-03-31-keda-cncf-sandbox.md │ │ ├── 2020-09-11-keda-2.0-beta.md │ │ ├── 2020-11-04-keda-2.0-release.md │ │ ├── 2021-03-26-migrating-to-github-container-registry.md │ │ ├── 2021-04-06-why-alibaba-cloud-uses-keda-for-app-autoscaling.md │ │ ├── 2021-05-27-azure-pipelines-scaler.md │ │ ├── 2021-06-24-announcing-http-add-on.md │ │ ├── 2021-08-04-keda-cast-ai.md │ │ ├── 2022-02-09-predictkube-scaler.md │ │ ├── 2022-03-10-how-zapier-uses-keda.md │ │ ├── 2022-08-10-keda-2.8.0-release.md │ │ ├── 2022-09-27-http-add-on-is-on-hold.md │ │ ├── 2022-12-12-keda-2.9.0-release.md │ │ ├── 2023-05-02-certificate-improvements.md │ │ ├── 2023-05-04-keda-survey.md │ │ ├── 2023-08-22-keda-cncf-graduation.md │ │ ├── 2025-09-15-gcp-deprecations.md │ │ └── _index.md │ ├── community.md │ ├── docs/ │ │ ├── 1.4/ │ │ │ ├── _index.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ └── redis-lists.md │ │ │ └── troubleshooting.md │ │ ├── 1.5/ │ │ │ ├── _index.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cron.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-lists.md │ │ │ │ └── redis-streams.md │ │ │ └── troubleshooting.md │ │ ├── 2.0/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ └── cluster.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-lists.md │ │ │ │ └── redis-streams.md │ │ │ └── troubleshooting.md │ │ ├── 2.1/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ └── cluster.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ └── redis-streams.md │ │ │ └── troubleshooting.md │ │ ├── 2.10/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ ├── 2.11/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ └── solr.md │ │ │ └── troubleshooting.md │ │ ├── 2.12/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ └── solr.md │ │ │ └── troubleshooting.md │ │ ├── 2.13/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ └── solr.md │ │ │ └── troubleshooting.md │ │ ├── 2.14/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ └── solr.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.15/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── dynatrace.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ ├── solr.md │ │ │ │ └── splunk.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.16/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── beanstalkd.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── dynatrace.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ ├── solr.md │ │ │ │ └── splunk.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.17/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── bound-service-account-token.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── metrics-server.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── beanstalkd.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── dynatrace.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── nsq.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ ├── solr.md │ │ │ │ ├── splunk.md │ │ │ │ └── temporal.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.18/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── bound-service-account-token.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── metrics-server.md │ │ │ │ ├── schema.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── beanstalkd.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── dynatrace.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── forgejo.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── nsq.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub-dm.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ ├── solarwinds.md │ │ │ │ ├── solr.md │ │ │ │ ├── splunk-observability.md │ │ │ │ ├── splunk.md │ │ │ │ ├── sumologic.md │ │ │ │ └── temporal.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.19/ │ │ │ ├── _index.md │ │ │ ├── addons/ │ │ │ │ └── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── bound-service-account-token.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── file-path.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── metrics-server.md │ │ │ │ ├── schema.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── beanstalkd.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── dynatrace.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── forgejo.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-resource.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── nsq.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub-dm.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ ├── solarwinds.md │ │ │ │ ├── solr.md │ │ │ │ ├── splunk-observability.md │ │ │ │ ├── splunk.md │ │ │ │ ├── sumologic.md │ │ │ │ └── temporal.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.2/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ └── events.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ └── redis-streams.md │ │ │ └── troubleshooting.md │ │ ├── 2.20/ │ │ │ ├── _index.md │ │ │ ├── addons/ │ │ │ │ └── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-secret-manager.md │ │ │ │ ├── aws.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── bound-service-account-token.md │ │ │ │ ├── configmap.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── file-path.md │ │ │ │ ├── gcp-secret-manager.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ ├── istio-integration.md │ │ │ │ ├── opentelemetry.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── admission-webhooks.md │ │ │ │ ├── cloud-events.md │ │ │ │ ├── cluster.md │ │ │ │ ├── metrics-server.md │ │ │ │ ├── schema.md │ │ │ │ └── security.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── events.md │ │ │ │ ├── faq.md │ │ │ │ ├── glossary.md │ │ │ │ ├── scaledjob-spec.md │ │ │ │ └── scaledobject-spec.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka-go.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── arangodb.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── beanstalkd.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── dynatrace.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── forgejo.md │ │ │ │ ├── gcp-cloud-tasks.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── github-runner.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-resource.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── nsq.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ ├── solace-pub-sub-dm.md │ │ │ │ ├── solace-pub-sub.md │ │ │ │ ├── solarwinds.md │ │ │ │ ├── solr.md │ │ │ │ ├── splunk-observability.md │ │ │ │ ├── splunk.md │ │ │ │ ├── sumologic.md │ │ │ │ └── temporal.md │ │ │ ├── setupscaler.md │ │ │ └── troubleshooting.md │ │ ├── 2.3/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ └── events.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ └── redis-streams.md │ │ │ └── troubleshooting.md │ │ ├── 2.4/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ └── metrics-server.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ ├── 2.5/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ └── metrics-server.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ ├── 2.6/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ └── metrics-server.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ ├── 2.7/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ └── metrics-server.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ ├── 2.8/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ └── metrics-server.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ ├── 2.9/ │ │ │ ├── _index.md │ │ │ ├── authentication-providers/ │ │ │ │ ├── _index.md │ │ │ │ ├── aws-eks.md │ │ │ │ ├── aws-kiam.md │ │ │ │ ├── azure-ad-pod-identity.md │ │ │ │ ├── azure-ad-workload-identity.md │ │ │ │ ├── azure-key-vault.md │ │ │ │ ├── environment-variable.md │ │ │ │ ├── gcp-workload-identity.md │ │ │ │ ├── hashicorp-vault.md │ │ │ │ └── secret.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── authentication.md │ │ │ │ ├── external-scalers.md │ │ │ │ ├── scaling-deployments.md │ │ │ │ ├── scaling-jobs.md │ │ │ │ └── troubleshooting.md │ │ │ ├── deploy.md │ │ │ ├── integrations/ │ │ │ │ ├── _index.md │ │ │ │ └── prometheus.md │ │ │ ├── migration.md │ │ │ ├── operate/ │ │ │ │ ├── _index.md │ │ │ │ ├── cluster.md │ │ │ │ ├── events.md │ │ │ │ └── metrics-server.md │ │ │ ├── reference/ │ │ │ │ └── faq.md │ │ │ ├── scalers/ │ │ │ │ ├── _index.md │ │ │ │ ├── activemq.md │ │ │ │ ├── apache-kafka.md │ │ │ │ ├── artemis.md │ │ │ │ ├── aws-cloudwatch.md │ │ │ │ ├── aws-dynamodb-streams.md │ │ │ │ ├── aws-dynamodb.md │ │ │ │ ├── aws-kinesis.md │ │ │ │ ├── aws-sqs.md │ │ │ │ ├── azure-app-insights.md │ │ │ │ ├── azure-data-explorer.md │ │ │ │ ├── azure-event-hub.md │ │ │ │ ├── azure-log-analytics.md │ │ │ │ ├── azure-monitor.md │ │ │ │ ├── azure-pipelines.md │ │ │ │ ├── azure-service-bus.md │ │ │ │ ├── azure-storage-blob.md │ │ │ │ ├── azure-storage-queue.md │ │ │ │ ├── cassandra.md │ │ │ │ ├── couchdb.md │ │ │ │ ├── cpu.md │ │ │ │ ├── cron.md │ │ │ │ ├── datadog.md │ │ │ │ ├── elasticsearch.md │ │ │ │ ├── etcd.md │ │ │ │ ├── external-push.md │ │ │ │ ├── external.md │ │ │ │ ├── gcp-pub-sub.md │ │ │ │ ├── gcp-stackdriver.md │ │ │ │ ├── gcp-storage.md │ │ │ │ ├── graphite.md │ │ │ │ ├── huawei-cloudeye.md │ │ │ │ ├── ibm-mq.md │ │ │ │ ├── influxdb.md │ │ │ │ ├── kubernetes-workload.md │ │ │ │ ├── liiklus-topic.md │ │ │ │ ├── loki.md │ │ │ │ ├── memory.md │ │ │ │ ├── metrics-api.md │ │ │ │ ├── mongodb.md │ │ │ │ ├── mssql.md │ │ │ │ ├── mysql.md │ │ │ │ ├── nats-jetstream.md │ │ │ │ ├── nats-streaming.md │ │ │ │ ├── new-relic.md │ │ │ │ ├── openstack-metric.md │ │ │ │ ├── openstack-swift.md │ │ │ │ ├── postgresql.md │ │ │ │ ├── predictkube.md │ │ │ │ ├── prometheus.md │ │ │ │ ├── pulsar.md │ │ │ │ ├── rabbitmq-queue.md │ │ │ │ ├── redis-cluster-lists.md │ │ │ │ ├── redis-cluster-streams.md │ │ │ │ ├── redis-lists.md │ │ │ │ ├── redis-sentinel-lists.md │ │ │ │ ├── redis-sentinel-streams.md │ │ │ │ ├── redis-streams.md │ │ │ │ ├── selenium-grid-scaler.md │ │ │ │ └── solace-pub-sub.md │ │ │ └── troubleshooting.md │ │ └── _index.md │ ├── enterprise.md │ ├── http-add-on/ │ │ ├── 0.14/ │ │ │ ├── _index.md │ │ │ ├── concepts/ │ │ │ │ ├── _index.md │ │ │ │ ├── architecture.md │ │ │ │ ├── routing.md │ │ │ │ └── scaling.md │ │ │ ├── getting-started/ │ │ │ │ └── _index.md │ │ │ ├── operations/ │ │ │ │ ├── _index.md │ │ │ │ ├── configure-interceptor.md │ │ │ │ ├── configure-observability.md │ │ │ │ ├── configure-tls.md │ │ │ │ ├── installation.md │ │ │ │ ├── migrate-httpscaledobject-to-interceptorroute.md │ │ │ │ └── troubleshooting.md │ │ │ ├── reference/ │ │ │ │ ├── _index.md │ │ │ │ ├── environment-variables.md │ │ │ │ ├── httpscaledobject.md │ │ │ │ ├── interceptorroute.md │ │ │ │ └── metrics.md │ │ │ └── user-guide/ │ │ │ ├── _index.md │ │ │ ├── autoscale-an-app.md │ │ │ ├── configure-cold-start.md │ │ │ ├── configure-ingress.md │ │ │ ├── configure-routing.md │ │ │ ├── configure-scaling.md │ │ │ └── configure-timeouts.md │ │ └── _index.md │ ├── resources.md │ ├── support.md │ ├── troubleshooting/ │ │ ├── 2.17/ │ │ │ └── api-server-throttling.md │ │ ├── 2.18/ │ │ │ └── api-server-throttling.md │ │ ├── _index.md │ │ ├── aws-keda-operator-iam.md │ │ ├── context-deadline-exceeded.md │ │ ├── gke-external-metrics.md │ │ ├── helm-upgrade-crd.md │ │ ├── istio-keda-faileddiscoverycheck.md │ │ ├── keda-external-metrics-issue.md │ │ ├── profiling-keda-components.md │ │ ├── proxy-network.md │ │ └── scaledobject-not-scale.md │ └── videos.md ├── data/ │ ├── faq.toml │ ├── faq20.toml │ ├── faq2_14.toml │ ├── faq2_15.toml │ └── faq2_19.toml ├── hugo.toml ├── includes/ │ └── get-involved.md ├── layouts/ │ ├── 404.html │ ├── _default/ │ │ ├── _markup/ │ │ │ ├── render-image.html │ │ │ └── render-link.html │ │ ├── baseof.html │ │ ├── card-info.html │ │ ├── list.lunr.json │ │ ├── single.html │ │ └── sitemap.xml │ ├── blog/ │ │ ├── list.html │ │ └── single.html │ ├── docs/ │ │ ├── list.html │ │ └── single.html │ ├── http-add-on/ │ │ ├── list.html │ │ └── single.html │ ├── index.html │ ├── index.redirects │ ├── partials/ │ │ ├── article.html │ │ ├── blog/ │ │ │ ├── article.html │ │ │ ├── list-hero.html │ │ │ ├── pagination.html │ │ │ ├── post-hero.html │ │ │ ├── posts.html │ │ │ └── rss-button.html │ │ ├── content.html │ │ ├── css.html │ │ ├── doc-version-selector.html │ │ ├── docs/ │ │ │ └── hero.html │ │ ├── favicon.html │ │ ├── footer.html │ │ ├── general-version-selector.html │ │ ├── headline-hash.html │ │ ├── hero.html │ │ ├── home/ │ │ │ ├── cncf.html │ │ │ ├── features.html │ │ │ ├── get-involved.html │ │ │ ├── hero.html │ │ │ ├── samples.html │ │ │ ├── scalers.html │ │ │ ├── video.html │ │ │ └── what-is.html │ │ ├── include.html │ │ ├── javascript.html │ │ ├── logo-section.html │ │ ├── meta.html │ │ ├── nav.html │ │ ├── navbar.html │ │ ├── scaler-layout.html │ │ ├── scaler-template.html │ │ ├── scalers.html │ │ ├── social-buttons.html │ │ └── youtube-embed.html │ ├── scalers/ │ │ └── list.html │ └── shortcodes/ │ ├── authentication-providers.html │ ├── collapsible.html │ ├── enterprise.html │ ├── faq.html │ ├── faq20.html │ ├── include.html │ ├── integrations.html │ ├── partners-icons.html │ ├── scalers-compact.html │ ├── supportedby-icons.html │ ├── troubleshooting.html │ └── user-icons.html ├── netlify.toml ├── package.json ├── schematics.pptx └── static/ ├── _redirects └── img/ └── keda-arch-new-source.excalidraw ================================================ FILE CONTENTS ================================================ ================================================ FILE: .devcontainer/devcontainer.json ================================================ { "name": "keda-docs", "image": "mcr.microsoft.com/devcontainers/javascript-node:24", "features": { "ghcr.io/devcontainers-community/features/deno": {} }, "postCreateCommand": "npm install" } ================================================ FILE: .editorconfig ================================================ root = true [*] end_of_line = lf [Makefile] indent_style = tab [*.{html,js,json,md,sass,toml,yaml}] indent_style = space indent_size = 2 [*.{js,json,md,sass,toml,yaml}] insert_final_newline = true ================================================ FILE: .gitattributes ================================================ # normalize all introduced text files to LF line endings (recognized by git) * text=auto # additionally declare text file types *.sh text eol=lf ================================================ FILE: .github/CODEOWNERS ================================================ # General owners * @kedacore/keda-docs # HTTP Add-on content/http-add-on/ @kedacore/keda-http-maintainers @kedacore/keda-docs # KEDA core content/docs/ @kedacore/keda-core-maintainers @kedacore/keda-docs ================================================ FILE: .github/PULL_REQUEST_TEMPLATE.md ================================================ _Provide a description of what has been changed_ ### Checklist - [ ] Commits are signed with Developer Certificate of Origin (DCO) Fixes # ================================================ FILE: .github/renovate.json5 ================================================ { $schema: "https://docs.renovatebot.com/renovate-schema.json", extends: [ // See https://docs.renovatebot.com/presets-config/#configbest-practices "config:best-practices", "customManagers:githubActionsVersions", "schedule:monthly", ":gitSignOff", ":prHourlyLimitNone", ], commitBodyTable: true, labels: ["dependencies"], // Experimental: OSV-based vulnerability alerts for direct dependencies osvVulnerabilityAlerts: true, postUpdateOptions: ["npmDedupe"], packageRules: [ { matchManagers: ["github-actions"], groupName: "GitHub Actions", }, { matchManagers: ["npm"], matchUpdateTypes: ["minor", "patch"], groupName: "npm Dependencies (non-major)", }, { matchFileNames: [".devcontainer/**"], pinDigests: false, }, ], vulnerabilityAlerts: { enabled: true, addLabels: ["security"], }, } ================================================ FILE: .github/reviewers.yml ================================================ # https://github.com/marketplace/actions/auto-assign-reviewer-by-files "**/*": - team: keda-docs # Any datadog.md file "**/datadog.md": - team: keda-core-datadog-notification ================================================ FILE: .github/workflows/auto-assign.yml ================================================ name: Auto Assign on: - pull_request_target jobs: assign_reviewer: runs-on: ubuntu-slim steps: - uses: shufo/auto-assign-reviewer-by-files@0a7fae44d02e841755d0caaac2ef05ad12a3bbc9 # v1.2.1 with: config: ".github/reviewers.yml" token: ${{ secrets.GH_AUTOMATION_PAT }} ================================================ FILE: .github/workflows/check-links.yml ================================================ # Adapted from @chalin's work on https://github.com/chalin/docsy-starter name: Links on: merge_group: pull_request: push: { branches: [main] } jobs: build-and-check-links: name: BUILD and CHECK LINKS runs-on: ubuntu-latest steps: - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6 - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6 with: node-version-file: .nvmrc cache: npm - run: npm install --omit=optional - run: npm run check:links ================================================ FILE: .github/workflows/pr-bot-welcome.yml ================================================ name: PR Welcome Bot on: pull_request_target: types: [opened] branches: - 'main' permissions: issues: write pull-requests: write jobs: pr_bot: name: PR Bot runs-on: ubuntu-slim steps: - name: 'Comment on PR' uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9 with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | await github.rest.issues.createComment({ owner: context.repo.owner, repo: context.repo.repo, issue_number: ${{ github.event.number }}, body: 'Thank you for your contribution! 🙏 We will review your PR as soon as possible.\n\n\n> While you are waiting, make sure to:\n\n\n- Add your contribution to all applicable KEDA versions\n- GitHub checks are passing\n- Is the DCO check failing? Here is [how you can fix DCO issues](https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md#i-didnt-sign-my-commit-now-what)\n\n\nLearn more about:\n- How to become a [listed end-user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) or a [listed commerical offering](https://github.com/kedacore/keda-docs#become-a-listed-keda-commercial-offering)\n- Our [contribution guide](https://github.com/kedacore/keda-docs/blob/main/CONTRIBUTING.md)' }); ================================================ FILE: .github/workflows/stale.yml ================================================ name: "Stale" on: schedule: - cron: "0 2 * * *" workflow_dispatch: permissions: actions: write issues: write pull-requests: write jobs: stale: runs-on: ubuntu-slim steps: - uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10 with: days-before-stale: 60 days-before-close: 7 operations-per-run: 30 # Issues exempt-issue-labels: "cant-touch-this,feature,security" stale-issue-label: "stale" stale-issue-message: > This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. close-issue-message: > This issue has been automatically closed due to inactivity. # PRs exempt-pr-labels: "cant-touch-this,feature,security" stale-pr-label: "stale" stale-pr-message: > This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. close-pr-message: > This pull request has been automatically closed due to inactivity. ================================================ FILE: .gitignore ================================================ node_modules/ /public .idea resources/ .DS_Store .hugo_build.lock # Link checker artifacts bin/ tmp/ # Local Netlify folder .netlify ================================================ FILE: .htmltest.yml ================================================ DirectoryPath: public EnforceHTTPS: true EnforceHTML5: true IgnoreDirectoryMissingTrailingSlash: true CheckExternal: false IgnoreAltMissing: true IgnoreEmptyHref: true IgnoreURLs: # /latest/ URLs are redirect-only paths handled by Netlify; no static page exists for them - /docs/latest/ - /http-add-on/latest/ # Temporal ignores # Deprecated and removed resources # Renamed pages - /docs/2.18/scalers/splunk-observability.md/ ================================================ FILE: .nvmrc ================================================ lts/* ================================================ FILE: .whitesource ================================================ { "scanSettings": { "baseBranches": [] }, "checkRunSettings": { "vulnerableCheckRunConclusionLevel": "failure", "displayMode": "diff" }, "issueSettings": { "minSeverityLevel": "LOW" } } ================================================ FILE: CONTRIBUTING.md ================================================ # Contributing to KEDA Thanks for helping make KEDA better 😍. There are many areas we can use contributions - documenting scalers, adding FAQ, troubleshooting, samples, and more. Our documentation is versioned so it's important to make the changes for the correct KEDA version. If you need to introduce a new version, we recommend reading our documentation about it [here](#working-with-documentation-versions). - [Contributing to KEDA](#contributing-to-keda) - [Getting Help](#getting-help) - [Local development](#local-development) - [Contributing New Documentation](#contributing-new-documentation) - [Adding blog post](#adding-blog-post) - [Adding scaler documentation](#adding-scaler-documentation) - [Writing documentation for a scaler](#writing-documentation-for-a-scaler) - [Writing documentation for a new authentication provider](#writing-documentation-for-a-new-authentication-provider) - [Add new Frequently Asked Question (FAQ)](#add-new-frequently-asked-question-faq) - [Add new troubleshooting guidance](#add-new-troubleshooting-guidance) - [Working with documentation versions](#working-with-documentation-versions) - [Preparing a new version](#preparing-a-new-version) - [Publishing a new version](#publishing-a-new-version) - [Developer Certificate of Origin: Signing your work](#developer-certificate-of-origin-signing-your-work) - [Every commit needs to be signed](#every-commit-needs-to-be-signed) - [I didn't sign my commit, now what?](#i-didnt-sign-my-commit-now-what) - [Changing the website](#changing-the-website) - [Adding a new filter option](#adding-a-new-filter-option) - [Listing KEDA Users and Commercial Offerings](#listing-keda-users-and-commercial-offerings) - [Become a listed KEDA user](#become-a-listed-keda-user) - [Become a listed KEDA commercial offering](#become-a-listed-keda-commercial-offering) ## Getting Help If you have a question about KEDA or how best to contribute, the [#KEDA](https://kubernetes.slack.com/archives/CKZJ36A5D) channel on the Kubernetes Slack ([get an invite if you don't have one already](https://slack.k8s.io/)) is a good place to start. We also have regular [community stand-ups](https://github.com/kedacore/keda#community) to track ongoing work and discuss areas of contribution. For any issues with the product you can [create an issue](https://github.com/kedacore/keda/issues/new) in this repo. ## Local development 1. Fork and clone this repository. 2. Install [Node](https://nodejs.org/). Hugo is bundled via the `hugo-extended` npm package — no separate Hugo install needed. 3. Install dependencies: ```console npm install ``` 4. Serve the site locally at [localhost:8888](http://localhost:8888): ```console npm run serve ``` 5. To do a one-off build (output goes to `public/`): ```console npm run build ``` 6. To check for broken links (runs a build first): ```console npm run check:links ``` ## Contributing New Documentation We provide easy ways to introduce new content: ### Adding blog post To add a new post to the [KEDA blog](https://keda.sh/blog): ```console npx hugo new blog/my-new-post.md ``` This creates a boilerplate Markdown file in `content/blog/my-new-post.md` whose contents you can modify. The following fields are required: - `title` - `date` (in `YYYY-MM-DD` format) - `author` > Note: Please ensure the file is named correctly, as it will be used as the blog post URL slug. Avoid defining an alias to rename the URL slug, as this goes against our convention. ### Adding scaler documentation To add documentation for a new KEDA [scaler](https://keda.sh/docs/scalers): ```console npx hugo new --kind scaler docs//scalers/my-new-scaler.md ``` This creates a boilerplate Markdown file in `content/docs//scalers/my-new-scaler.md` whose contents you can modify. Make sure to update the following metadata fields: - `title` - `availability` - `maintainer` - `description` ### Writing documentation for a scaler In order to maintain the style consistency across different scalers, all the parameters which are listed have to be written using this convention: - name - Description. (Values: x, y, z, Default: y, Optional, Extra Info) If a parameter is required or doesn't have defined/default values, the missing info should be removed from the pattern. Here are a few examples: > - `targetMetricValue` - Target value for your metric. > - `metricFilter` - Aggregation method of the metric. (Values: `max`, `min`, `average`, `sum`, `variance`, Default: `average`, Optional) > - `metricPeriod` - Granularity of the metric. (Default: `300`, Optional) > - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional, Required when `topicName` is specified) ### Writing documentation for a new authentication provider To add documentation for a new [provider](https://keda.sh/docs/concepts/authentication): ```console npx hugo new --kind provider docs//providers/my-new-provider.md ``` This creates a boilerplate Markdown file in `content/docs//providers/my-new-provider.md` whose contents you can modify. Make sure to update the following metadata fields: - `title` ### Add new Frequently Asked Question (FAQ) To update the KEDA [FAQ page](https://keda.sh/docs/faq), update the TOML file referenced by `versionData` in `content/docs//reference/faq.md`. Here's an example question/answer pair: ```toml [[qna]] q = "How can I add a new question/answer pair?" a = "You're looking at it! 😀" ``` ### Add new troubleshooting guidance To add a new section to the [troubleshooting page](https://keda.sh/docs/troubleshooting): ```console npx hugo new troubleshooting//my-new-issue.md ``` To adjust the order in which the troubleshooting tiles appear, use the `weight` parameter in each page's metadata. ## Working with documentation versions The KEDA documentation is versioned. Each version has its own subdirectory under [content/docs](content/docs). To add a new version, follow these steps: 1. Copy the directory for the most recent version: ```console cp -rf content/docs/ content/docs/ ``` 2. Copy the file for the most recent faq data in the `data` directory: ```console cp -rf data/faq data/faq ``` 3. Update the `versionData` option in `content/docs//reference/faq.md`, replacing `NEW_FAQ_FILE_NAME` with the file name of the faq data for the new version: ```text {{< faq20 versionData="NEW_FAQ_FILE_NAME" >}} ``` By default, new documentation versions are not listed as available version so it's safe to make changes to them. After every release, the version will be published as new version. ### Preparing a new version Remember to create the folder for next version with already existing docs in current version. Make sure that the version on `content/docs/{next-version}/deploy.md` is updated and uses the next version, instead of the current one. Ensure that Kubernetes cluster version is updated as well. Ensure that compatibility matrix on `content/docs/{next-version}/operate/cluster.md` is updated with the compatibilities for the incoming version. Update the new version in the `params.unreleased.docs` list in [hugo.toml](hugo.toml). ### Publishing a new version Once a version is ready to be published, we must add the version to the `params.versions.docs` list in [hugo.toml](hugo.toml). More recent versions should be placed first in the list (ordering _does_ matter because the first element in that list is considered the latest version). > Note: Remember to [prepare the next version](#preparing-a-new-version). ## Developer Certificate of Origin: Signing your work ### Every commit needs to be signed The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Here is the full text of the DCO, reformatted for readability: ```text By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ``` Contributors sign-off that they adhere to these requirements by adding a `Signed-off-by` line to commit messages. ```text This is my commit message Signed-off-by: Random J Developer ``` Git even has a `-s` command line option to append this automatically to your commit message: ```console git commit -s -m 'This is my commit message' ``` Each Pull Request is checked whether or not commits in a Pull Request do contain a valid Signed-off-by line. ### I didn't sign my commit, now what? No worries - You can easily replay your changes, sign them and force push them! ```console git checkout git reset $(git merge-base main ) git add -A git commit -sm "one commit on " git push --force ``` ## Changing the website ### Adding a new filter option To add a new filter option, simply follow these steps: 1. Navigate to the doc file you want to annotate. 2. In the frontmatter, add your new filter option: ```toml FILTER_NAME = "filter_value" ``` Replace `FILTER_NAME` with any desired name of your choice. Same applies to the value. 3. In `layouts/_default/list.lunr.json`, just before the closing parenthesis, append your new option: ```text "FILTER_NAME" $scalers.Params.FILTER_NAME ``` 4. In `hugo.toml`, in the `params.lunr` section, add your new filter option's name to both arrays: ```toml vars = ["title", "maintainer", "description", "availability", "category", "type", "FILTER_NAME"] params = ["availability", "maintainer", "category", "type", "FILTER_NAME"] ``` 5. In `assets/js/scaler-search.js`, in the `lunr()` callback where `this.field` is called, append your field: ```javascript this.field("FILTER_NAME", { boost: 5, }); ``` And where `parse[doc.title]` is built, add your field: ```javascript parse[doc.title] = { href: doc.href, title: doc.title, maintainer: doc.maintainer, description: doc.description, availability: doc.availability, category: doc.category, type: doc.type, FILTER_NAME: doc.FILTER_NAME, }; ``` 6. In `layouts/partials/scaler-layout.html`, locate the div with class `filter-options` and add this new block: ```html
FILTER_NAME
{{ $FILTER_NAME := slice }} {{ range $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" }} {{ with $scalers.Params.FILTER_NAME }} {{ $FILTER_NAME = $categories | append ($scalers.Params.FILTER_NAME) }} {{ $FILTER_NAME = uniq $FILTER_NAME }} {{ end }} {{ end }} {{ range $FILTER_NAME }} {{ $item := . }}
{{ end }}
``` 7. Save your changes and rebuild your frontend. ## Listing KEDA Users and Commercial Offerings ### Become a listed KEDA user! Are you using KEDA in production? Do you want to become a [listed user](https://keda.sh/community/#users)? Say no more! You can easily get listed by following these steps: 1. Upload your logo to `static/img/logos/` _(350x180)_ 2. Configure your company as a new user in `hugo.toml` _(sorted alphabetically)_ ```toml [[params.users]] url = "https://coralogix.com/" logo = "coralogix.gif" ``` Here's a good example of [Coralogix becoming a listed user](https://github.com/kedacore/keda-docs/pull/182)! ### Become a listed KEDA commercial offering! Do you offer commercial support for KEDA and want to become a [listed commercial offering](https://keda.sh/enterprise)? Say no more! To be listed as a KEDA commercial offering, organizations must meet the following criteria: - Demonstrate a commitment to KEDA's maintenance and improvement. - On average, have pull requests accepted monthly into KEDA or related projects for features and/or improvements. - Have made a substantial contribution to the development of KEDA or related projects. - Help triage and comment on issues across the KEDA ecosystem at least 3 times per month. - Demonstrate an area of expertise in the KEDA ecosystem. - Example: Employing one or more KEDA maintainers. - Example: Owning a specific high-impact feature or process. - Participate in KEDA's governance. - At least 1 member of the vendor's team attends the community meetings at least 50% of the time. - Be active KEDA thought leaders. - Example: Sponsoring staff for KEDA booths or community events. - Example: Giving talks related to KEDA or its ecosystem. - Provide enterprise-level support and functionality for KEDA or products based directly on it. If any questions arise regarding eligibility, the KEDA maintainers will make the final decision. If your organization meets these requirements, you can request to be listed by following these steps: 1. Open a pull request and provide evidence in the PR description showing how the requirements above have been met. 2. Upload your logo to `static/img/logos/` _(350x180)_ 3. Configure your company as a new vendor in `hugo.toml` _(sorted alphabetically)_ ```toml [[params.vendors]] name = "Red Hat" logo = "vendors/red-hat.png" description = """ Red Hat integrates KEDA with OpenShift through the **Custom Metrics Autoscaler** (CMA) available through the OpenShift Marketplace. """ urls = [ { text = "Learn more about the CMA", url = "https://cloud.redhat.com/blog/custom-metrics-autoscaler-on-openshift" } ] ``` ================================================ FILE: LICENSE ================================================ Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright 2020 The KEDA Authors. and others that have contributed code to the public domain. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ================================================ FILE: MAINTAINERS.md ================================================ # Kubernetes Event-driven Autoscaling (KEDA) Maintainers You can find a recent update of the maintainers [here](https://github.com/kedacore/governance/blob/main/MEMBERS.md). ================================================ FILE: Makefile ================================================ HTMLTEST_DIR=tmp HTMLTEST?=htmltest # Specify as make arg if different HTMLTEST_ARGS?=--skip-external DOCS=public/docs LATEST_VERSION=$(shell grep -e '^docs' hugo.toml | grep -oe '[0-9][0-9]*.[0-9][0-9]' | head -1) HTTP_ADDON_LATEST_VERSION=$(shell grep -e '^http-add-on' hugo.toml | grep -oe '[0-9][0-9]*.[0-9][0-9]' | head -1) # Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy ifeq (, $(shell which $(HTMLTEST))) override HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest ifeq (, $(shell which $(HTMLTEST))) GET_LINK_CHECKER_IF_NEEDED=get-link-checker endif endif check-links: $(GET_LINK_CHECKER_IF_NEEDED) make-redirects-for-checking $(HTMLTEST) $(HTMLTEST_ARGS) find public/* -type l -ls -exec rm -f {} \; make-redirects-for-checking: @if [ -z $(LATEST_VERSION) ]; then \ echo "Failed to extract LATEST_VERSION. Cannot setup symlinks for checking"; \ exit 1; \ fi @if [ -z $(HTTP_ADDON_LATEST_VERSION) ]; then \ echo "Failed to extract HTTP_ADDON_LATEST_VERSION. Cannot setup symlinks for checking"; \ exit 1; \ fi @echo "Creating symlinks of 'latest' to $(LATEST_VERSION) for the purpose of link checking" (cd public && rm -f scalers && ln -s docs/$(LATEST_VERSION)/scalers scalers) (cd public/docs && rm -f latest && ln -s $(LATEST_VERSION) latest) (cd public/http-add-on && rm -f latest && ln -s $(HTTP_ADDON_LATEST_VERSION) latest) get-link-checker: rm -Rf $(HTMLTEST_DIR)/bin curl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin clean: rm -rf $(HTMLTEST_DIR) public/* resources ================================================ FILE: README.md ================================================ # KEDA - Docs Documentation and landing page for the KEDA project at [keda.sh][]. - [Become a listed KEDA user!](CONTRIBUTING.md#become-a-listed-KEDA-user) - [Become a listed KEDA commercial offering!](CONTRIBUTING.md#become-a-listed-KEDA-commercial-offering) ## Contributing We welcome issues and PRs! For details, see [Contributing to KEDA][]. If you submit a PR, Netlify will automatically create a [deploy preview][] so that you can view your changes. Once merged, Netlify automatically deploys to the production site [keda.sh][]. To see deploy logs and more, visit project's [dashboard][] -- Netlify login required. [Contributing to KEDA]: CONTRIBUTING.md [dashboard]: https://app.netlify.com/sites/keda [deploy preview]: https://www.netlify.com/blog/2016/07/20/introducing-deploy-previews-in-netlify/ [keda.sh]: https://keda.sh ================================================ FILE: archetypes/blog.md ================================================ +++ title = "{{ replace .Name "-" " " | title }}" date = {{ dateFormat "2006-01-02" .Date }} author = "Scaley McAutoscaler" +++ ================================================ FILE: archetypes/provider.md ================================================ +++ title = "{{ replace .Name "-" " " | title }}" +++ Authentication provider description. ```yaml code ``` ================================================ FILE: archetypes/scaler.md ================================================ +++ title = "{{ replace .Name "-" " " | title }}" availability = "" maintainer = "" description = "Insert description here" +++ ### Trigger Specification This specification describes the `*Scaler Type*` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: *Scaler Type* metadata: namespace: SYS.ELB ``` **Parameter list:** - `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Endpoint to verify the identity against. The user will need access to read data from Huawei Cloudeye. ### Example *Provide an example of how to configure the trigger, preferably using TriggerAuthentication* ================================================ FILE: archetypes/troubleshooting.md ================================================ +++ title = "Replace this with a question" +++ And provide the answer here... ================================================ FILE: assets/js/alpine.js ================================================ import Alpine from "alpinejs"; window.Alpine = Alpine; Alpine.start(); ================================================ FILE: assets/js/docsearch.js ================================================ import docsearch from "@docsearch/js"; import * as params from "@params"; function meta(name) { const element = document.querySelector(`meta[name="docsearch:${name}"]`); return element ? element.content : ""; } const currentTag = meta("tag"); const currentProduct = meta("product"); // Each tag encodes product + version in one value (e.g. "docs-2.19"). // This avoids needing a cross-attribute filter like (product AND version) // which Algolia's filter syntax does not support in OR groups. const tags = { docs: "docs-" + params.latestDocs, "http-add-on": "http-add-on-" + params.latestHttpAddon, }; if (currentProduct in tags && currentTag) { tags[currentProduct] = currentTag; } const facetFilters = Object.values(tags) .map((tag) => "tag:" + tag) .concat("tag:blog"); try { docsearch({ apiKey: params.apiKey, appId: params.appId, indices: [ { name: params.indexName, searchParameters: { facetFilters: [facetFilters] }, }, ], container: "#navbar-search", insights: true, }); } catch (err) { console.error("DocSearch failed to initialize:", err); } ================================================ FILE: assets/js/scaler-search.js ================================================ import lunr from "lunr"; window.addEventListener("DOMContentLoaded", () => { "use strict"; const input = document.getElementById("search-input"); if (!input) return; let index; let debounceTimer; const currentUrl = window.location.pathname; const currentLocation = String(currentUrl).split("/"); const currentVersion = currentLocation[2]; const form = document.getElementById("search"); const target = document.querySelector(".is-search-result"); const filterIcon = document.querySelector(".filter-icon"); const filterOptions = document.querySelector(".filter-options"); const searchResultCount = document.querySelector(".results"); const template = document.getElementById("is-search-template"); const interval = 500; let query = input.value.trim(); let parse = {}; let searchQueue = []; let checkboxes = document.querySelectorAll('input[name="resource_filter"]'); // fetch all scalers on initial load if (!query) { initSearchIndex(); } // logic for input search input.addEventListener( "input", function (event) { event.preventDefault(); clearTimeout(debounceTimer); const keywords = input.value.trim(); query = keywords; debounceTimer = setTimeout(initSearchIndex, interval); // clear out all the scaler item card during search while (target.firstChild.nextSibling) { target.removeChild(template.nextSibling.nextElementSibling); } }, false, ); // logic for category filter checkboxes.forEach((checkbox) => { checkbox.addEventListener("change", function (event) { if (checkbox.checked) { const inputValue = event.target.value.split(" "); // for single queries with spacing, use the first word const inputQuery = inputValue[0]; searchQueue.push(inputQuery); query = searchQueue.join(" "); initSearchIndex(); } if (!checkbox.checked) { const inputValue = event.target.value.split(" "); // for single queries with spacing, use the first word const inputQuery = inputValue[0]; searchQueue = searchQueue.filter((word) => word != inputQuery); query = searchQueue.join(" "); initSearchIndex(); } // clear out all the scaler item card during search while (target.firstChild.nextSibling) { target.removeChild(template.nextSibling.nextElementSibling); } }); }); // show filter options on mobile filterIcon.addEventListener("click", function () { if (filterOptions.style.display === "none" || filterOptions.style.display === "") { filterOptions.style.display = "flex"; } else { filterOptions.style.display = "none"; } }); async function initSearchIndex() { const builtInScalers = await fetch("/index.json", { method: "GET" }) .then((response) => response.json()) .then((data) => { return data; }) .catch((err) => console.error("error:", err)); const externalScalerUrl = "https://artifacthub.io/api/v1/packages/search?offset=0&limit=20&facets=false&kind=8&deprecated=false&sort=relevance"; const externalScalersData = await fetch(externalScalerUrl) .then((response) => response.json()) .then((data) => { return data.packages; }) .catch((err) => console.error("error:", err)); const externalScalers = (externalScalersData || []).map((scaler) => ({ type: "external", availability: `v${scaler.version}+`, title: scaler.display_name, maintainer: scaler.repository.organization_name ?? scaler.repository.user_alias, href: "https://artifacthub.io/packages/keda-scaler/" + scaler.repository.name + "/" + scaler.normalized_name, version: currentVersion, description: scaler.description, category: null, })); const scalers = [...(builtInScalers || []), ...externalScalers]; index = lunr(function () { const documents = scalers; this.ref("title"); this.field("title", { boost: 20, usePipeline: true, wildcard: lunr.Query.wildcard.TRAILING, presence: lunr.Query.presence.REQUIRED, }); this.field("maintainer", { boost: 15, }); this.field("href", { boost: 15, }); this.field("description", { boost: 10, }); this.field("availability", { boost: 5, }); this.field("category", { boost: 10, }); this.field("type", { boost: 20, }); documents.forEach(function (doc) { if (doc.version === currentVersion) { this.add(doc); parse[doc.title] = { href: doc.href, title: doc.title, maintainer: doc.maintainer, description: doc.description, availability: doc.availability, category: doc.category, type: doc.type, }; } }, this); }); search(query); } function search(keywords) { // show all scalers by default let queryString = index.search(""); /* Lunr only matches complete words by default. If an exact match fails, retry with a trailing wildcard to support prefix matching. */ if (keywords.length > 0) { queryString = index.search(keywords); queryString = queryString.length <= 0 ? index.search(`${keywords}*`) : queryString; } const results = queryString; if ("content" in template) { // show result count const title = document.createElement("h3"); title.id = "search-results"; title.className = "subtitle is-size-3"; if (results.length == 0) title.textContent = `No results found`; else if (results.length == 1) title.textContent = `Found 1 result`; else if (results.length > 1 && keywords === "") title.textContent = `${results.length} scalers available`; else title.textContent = `Found ${results.length} results`; searchResultCount.replaceChildren(title); // show the matched result results.forEach(function (result) { const doc = parse[result.ref]; const element = template.content.cloneNode(true); element.querySelector(".badge").textContent = doc.type; element.querySelector(".scaler-title").textContent = doc.title; element.querySelector(".scaler-title").setAttribute("href", doc.href); if (doc.type === "external") { element.querySelector(".badge").style.color = "purple"; } if (doc.description) { element.querySelector(".description").textContent = doc.description; } if (doc.maintainer) { element.querySelector(".maintainer").textContent = doc.maintainer; } if (doc.availability) { element.querySelector(".availability").textContent = doc.availability; } target.appendChild(element); }, this); } } }); ================================================ FILE: assets/js/site.js ================================================ // Anchor link scroll offset — compensates for the fixed navbar. const navbar = document.getElementsByClassName("navbar")[0]; const navbarHeight = navbar ? navbar.offsetHeight : 0; const extraPadding = 15; const navbarOffset = -1 * (navbarHeight + extraPadding); function shiftWindow() { scrollBy(0, navbarOffset); } window.addEventListener("hashchange", shiftWindow); window.addEventListener("pageshow", shiftWindow); if (window.location.hash) shiftWindow(); // Copy-to-clipboard for FAQ / troubleshooting permalink buttons. function copyPermalink(id) { const url = `${window.location.origin}${window.location.pathname}#${id}`; const container = document.getElementById(id); if (!navigator.clipboard) { console.error("Clipboard API not available"); return; } navigator.clipboard.writeText(url).then(() => { container.classList.add("copy-text-active"); setTimeout(() => container.classList.remove("copy-text-active"), 2500); }, (err) => { console.error("Could not copy text:", err); }); } const copyBtns = document.querySelectorAll(".copyBtn"); copyBtns.forEach((btn) => { btn.addEventListener("click", (event) => { event.stopPropagation(); copyPermalink(btn.getAttribute("id")); }); }); // Expand collapsed FAQ/troubleshooting section matching the URL hash. window.addEventListener("DOMContentLoaded", () => { "use strict"; const hash = window.location.hash.slice(1); const cardContents = document.querySelectorAll(".card-content-dropdown"); cardContents.forEach((item) => { const id = item.getAttribute("id"); if (hash === id) { item.style.display = ""; } else { item.style.display = "none"; } }); }); ================================================ FILE: assets/sass/card.sass ================================================ .card height: 100% box-shadow: 5px 10px 15px #e4e4e4; border-radius: 5px display: flex flex-direction: column &.is-dark background-color: $black-bis color: $white-bis &-content flex: 1 &-is-wrapped flex-wrap: wrap &.is-collapsible & + & margin-top: 0.5rem ================================================ FILE: assets/sass/content.sass ================================================ .doc-hero margin-bottom: 1.5rem .title sup line-height: 0 .content a sup margin-left: 0.1rem ol li pre margin-bottom: 1rem .highlight margin-bottom: 1rem // Allow horizontal scrolling for larger tables table display: block overflow-x: auto max-width: 100% &.is-constrained max-width: 90ch &.has-bottom-margin margin-bottom: 8rem // Headline hashes .headline-hash display: none margin-left: 0.25rem color: $secondary @for $i from 1 through 6 h#{$i} &:hover > .headline-hash display: inline figure img +desktop width: 100% @media screen and (min-width: 769px) .is-search-result > .column, .is-external-search-result > .column width: 50% ================================================ FILE: assets/sass/nav.sass ================================================ =active font-weight: $weight-bold a color: $primary !important =split-x display: flex flex-direction: row justify-content: space-between .nav padding-bottom: 2rem &-subsection &-title a font-weight: 500 color: $dark +split-x &.is-active +active &-section &-title a font-weight: 600 color: $dark +split-x &.is-active +active &-section, &-subsection &-toc padding: 0.35rem 0 0.75rem 1rem //padding: 0.75rem 0 0.75rem 1rem li a color: $grey ul + ul margin-top: 0.3rem ul.nav-section-links margin: 0.5rem 0 0.75rem 1rem li.nav-section-link font-size: 1.1rem a color: $dark &.is-active +active & + li.nav-section-link margin-top: 0.4rem & + & margin-top: 1rem .docs-menu--desktop display: flex .docs-menu--mobile display: none .scrolled background: #1d1c29 !important transition: background 1000ms .navbar-link, .navbar-item color: white; .navbar-link, .navbar-end .navbar-item &:hover color:#00aeff .navbar-dropdown .navbar-item color: #4a4a4a @media screen and (max-width: 1024px) .is-fixed-top overflow: hidden .is-left-padded padding-left: 40px .docs-menu--mobile display: flex .docs-menu--desktop display: none @media screen and (max-width: 1023px) .navbar-link, .navbar-item color: $dark ================================================ FILE: assets/sass/style.sass ================================================ @charset "utf-8" // Site-specific variables here $keda-blue: #326de6 $keda-light-blue: #679bf0 $twitter-blue: rgb(29, 161, 242) $slack-green: #2EB67D $k8s-blue: #326ce5 // Initial Bulma imports @import "bulma/sass/utilities/initial-variables" @import "bulma/sass/utilities/functions" // Bulma-specific overrides $primary: $keda-blue $secondary: $keda-light-blue $footer-color: $white-bis $footer-background-color: $black $navbar-height: 4rem $navbar-burger-color: $primary $code: $primary $code-background: $white-bis $modal-content-width: 50% $list-radius: none $input-icon-color: $secondary $input-icon-active-color: $primary $input-color: $black // Font overrides {{ if $fonts := site.Params.fonts }} // Sans-serif font {{ with (index (where $fonts ".type" "sans_serif") 0).name }} $family-sans-serif: "{{ . }}", BlinkMacSystemFont, -apple-system, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", "Helvetica", "Arial", sans-serif {{ end }} // Monospace font {{ with (index (where $fonts ".type" "monospace") 0).name }} $family-monospace: "{{ . }}", monospace {{ end }} {{ end }} // Final Bulma imports @import "bulma/sass/utilities/derived-variables" $card-border: 1.5px solid $grey-lighter $colors: mergeColorMaps(("secondary": ($secondary, $white-bis), "slack-green": ($slack-green, $white), "twitter-blue": ($twitter-blue, $white), "orange": ($orange, $white)), $colors) $card-shadow: none $card-color: $black //$card-content-padding: 1.5rem 2rem //$card-header-padding: 1rem $card-content-padding $card-shadow: none $card-header-weight: $weight-bold $card-header-shadow: 0 0.125em 0.125em rgba($scheme-invert, 0.1) $card-footer-border-top: $card-border $message-header-color: $dark !important $message-body-color: $dark !important $message-header-padding: 1em 1.25em $message-body-padding: $message-header-padding $hero-body-padding: 4rem 1.5rem // Bulma core @import "bulma/sass/utilities/_all" @import "bulma/sass/base/_all" @import "bulma/sass/elements/container" @import "bulma/sass/grid/columns" @import "bulma/sass/grid/tiles" @import "bulma/sass/layout/hero" @import "bulma/sass/layout/section" @import "bulma/sass/layout/footer" // Elements // @import "bulma/sass/elements/box" @import "bulma/sass/elements/button" @import "bulma/sass/elements/content" @import "bulma/sass/elements/icon" // @import "bulma/sass/elements/image" // @import "bulma/sass/elements/notification" // @import "bulma/sass/elements/progress" // @import "bulma/sass/elements/table" @import "bulma/sass/elements/tag" @import "bulma/sass/elements/title" // @import "bulma/sass/elements/other" // Forms @import "bulma/sass/form/shared" @import "bulma/sass/form/input-textarea" // @import "bulma/sass/form/checkbox-radio" // @import "bulma/sass/form/select" // @import "bulma/sass/form/file" @import "bulma/sass/form/tools" // Components // @import "bulma/sass/components/breadcrumb" @import "bulma/sass/components/card" @import "bulma/sass/components/dropdown" @import "bulma/sass/components/level" @import "bulma/sass/components/list" @import "bulma/sass/components/media" @import "bulma/sass/components/menu" @import "bulma/sass/components/message" @import "bulma/sass/components/modal" @import "bulma/sass/components/navbar" @import "bulma/sass/components/pagination" // @import "bulma/sass/components/panel" // @import "bulma/sass/components/tabs" // Custom CSS @import "card" @import "content" @import "nav" *, *::before, *::after max-width: 100vw .has-extra-top-margin margin-top: 1.5rem .has-extra-sm-right-margin margin-right: 0.5rem .list-item padding: 1rem 1.5rem .content margin-top: 0.5rem .title, .subtitle &.has-shadow text-shadow: 0 0 10px #000 .card &.is-borderless border: none &.has-extra-bottom-margin margin-bottom: 2rem .has-mouse-icon &:hover cursor: pointer .is-sticky position: sticky position: -webkit-sticky top: $navbar-height + 2.5rem .is-page display: flex flex-direction: column min-height: 100vh .is-main flex: 1 overflow: hidden =logo($desk, $tab, $touch) +desktop width: $desk +tablet-only width: $tab +mobile width: $touch .is-cncf-logo +logo(40%, 20%, 70%) .is-hero-logo +logo(75%, 80%, 50%) .is-footer-logo +logo(40%, 60%, 40%) .is-org-logo width: auto max-height: 8rem .is-bold-letter color: $secondary border-bottom: 4px solid $primary .title .icon margin-left: 0.75rem .has-background-pattern background-color: transparent background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='100%25' height='100%25' viewBox='0 0 1600 800'%3E%3Cg stroke='%23000' stroke-width='66.7' stroke-opacity='0.05' %3E%3Ccircle fill='%2324CEFF' cx='0' cy='0' r='1800'/%3E%3Ccircle fill='%232fc2f4' cx='0' cy='0' r='1700'/%3E%3Ccircle fill='%2337b6e8' cx='0' cy='0' r='1600'/%3E%3Ccircle fill='%233daadc' cx='0' cy='0' r='1500'/%3E%3Ccircle fill='%23419ecf' cx='0' cy='0' r='1400'/%3E%3Ccircle fill='%234492c2' cx='0' cy='0' r='1300'/%3E%3Ccircle fill='%234587b5' cx='0' cy='0' r='1200'/%3E%3Ccircle fill='%23467ca8' cx='0' cy='0' r='1100'/%3E%3Ccircle fill='%2345719b' cx='0' cy='0' r='1000'/%3E%3Ccircle fill='%2344668e' cx='0' cy='0' r='900'/%3E%3Ccircle fill='%23425c81' cx='0' cy='0' r='800'/%3E%3Ccircle fill='%233f5274' cx='0' cy='0' r='700'/%3E%3Ccircle fill='%233b4867' cx='0' cy='0' r='600'/%3E%3Ccircle fill='%23363f5a' cx='0' cy='0' r='500'/%3E%3Ccircle fill='%2331364e' cx='0' cy='0' r='400'/%3E%3Ccircle fill='%232c2d42' cx='0' cy='0' r='300'/%3E%3Ccircle fill='%23252536' cx='0' cy='0' r='200'/%3E%3Ccircle fill='%231F1D2B' cx='0' cy='0' r='100'/%3E%3C/g%3E%3C/svg%3E") background-attachment: fixed background-size: cover .has-extra-padding margin: 1.5rem 0 .is-youtube-embed width: 100% height: 20rem .pagination &.has-bottom-margin margin-bottom: 4rem .footer .buttons +touch margin-top: 1rem a color: $secondary &:hover color: #00aeff #cncf &:hover color: #00aeff hr &.is-thick margin: 3rem 0 .subtitle a color: $secondary !important &:hover color: $keda-blue !important .navbar-item .icon margin-left: 0.1rem .buttons &.are-spaced .button:not(:first-child) margin-left: 0.5rem .has-no-shadow box-shadow: none !important .is-info-light background: hsl(206, 70%, 96%) .badge border: 1px solid #dbdbdb border-radius: 20px padding: 3px 6px color: blue font-size: 1rem .copyBtn padding: 10px background: none height: 50% margin-right: 10px margin-top: 5px color: #ffffff font-size: 18px border: none outline: none border-radius: 10px cursor: pointer &:focus outline: 2px solid #5784f5 &:hover outline: 2px solid #5784f5 &:active background: #809ce2 &:before content: "Copied" position: absolute top: -45px right: 0px background: #5c81dc padding: 8px 10px border-radius: 20px font-size: 15px display: none &:after content: "" position: absolute top: -20px right: 25px width: 10px height: 10px background: #5c81dc transform: rotate(45deg) display: none .copy-text-active .copyBtn:before, .copy-text-active .copyBtn:after, display: block @media screen and (max-width: 1024px) .section width: 100vw .underline--magical background-image: linear-gradient(to right, rgb(250, 112, 154) 0%, rgb(254, 225, 64) 100%) background-repeat: no-repeat background-size: 100% 0.2em background-position: 0 88% transition: background-size 0.25s ease-in-out &:hover background-size: 100% 88% .underline--magical-1 background-image: linear-gradient(to right, #B2FEFA 0%, #0ED2F7 100%) background-repeat: no-repeat background-size: 100% 0.2em background-position: 0 88% transition: background-size 0.25s ease-in-out &:hover background-size: 100% 88% .underline--magical-2 background-image: linear-gradient(to right, #E29587 0%, #D66D75 100%) background-repeat: no-repeat background-size: 100% 0.2em background-position: 0 88% transition: background-size 0.25s ease-in-out &:hover background-size: 100% 88% .underline--magical-3 background-image: linear-gradient(to right, #A7BFE8 0%, #6190E8 100%) background-repeat: no-repeat background-size: 100% 0.2em background-position: 0 88% transition: background-size 0.25s ease-in-out &:hover background-size: 100% 88% .underline--magical-4 background-image: linear-gradient(to right, #F8FFAE 0%, #43C6AC 100%) background-repeat: no-repeat background-size: 100% 0.2em background-position: 0 88% transition: background-size 0.25s ease-in-out &:hover background-size: 100% 88% .underline--magical-5 background-image: linear-gradient(to right, #FDB99B 0%, #CF8BF3 100%) background-repeat: no-repeat background-size: 100% 0.2em background-position: 0 88% transition: background-size 0.25s ease-in-out &:hover background-size: 100% 88% @media screen and (min-width: 769px) .md-height-desktop height: 9rem .filter-icon display: none .filter-options display: inline-block .filter-pane padding-left: 0 padding-top: 20px @media screen and (max-width: 769px) .filter-icon padding: 0.5rem cursor: pointer border: 1px solid #DBDBDB font-size: 18px border-radius: 0.4rem display: inline-block &:hover border: 1px solid #000000 .filter-options display: none .filter-pane padding-left: 20px padding-top: 10px ================================================ FILE: content/blog/2020-03-31-keda-cncf-sandbox.md ================================================ +++ title = "Kubernetes Event-driven Autoscaling (KEDA) is now an official CNCF Sandbox project 🎉" date = 2020-03-31 author = "KEDA Maintainers" aliases = [ "/blog/keda-cncf-sandbox/" ] +++ Over the past year, We've been contributing to Kubernetes Event-Driven Autoscaling (KEDA), which makes application autoscaling on Kubernetes dead simple. If you have missed it, read about it in our ["Exploring Kubernetes-based event-driven autoscaling (KEDA)"](https://blog.tomkerkhove.be/2019/06/11/a-closer-look-at-kubernetes-based-event-driven-autoscaling-keda/) blog post. We started the KEDA project to address an essential missing feature in the Kubernetes autoscaling story. Namely, the ability to autoscale on arbitrary metrics. Before KEDA, users were only able to autoscale based on metrics such as memory and CPU usage. While these values are essential for autoscaling, they disregard a rich world of external metrics from sources such as Azure, AWS, GCP, Redis, and Kafka (among many more). To address this need, KEDA provides a simple, unified API to autoscale deployments without an in-depth knowledge of Kubernetes internals. With KEDA, users can now treat their Kubernetes deployments like FaaS or PaaS applications with ease! In the incredible year since we announced KEDA publicly, adoption has been increasing, and every week we find more passionate and excited members in our weekly community standups. Members of the Kubernetes community have been incredibly accepting. They have been providing feedback, contributing features, and offering great suggestions for the future of our project. On November 19, 2019, we released [Kubernetes Event-Driven Autoscaling (KEDA) v1.0](https://cloudblogs.microsoft.com/opensource/2019/11/19/keda-1-0-release-kubernetes-based-event-driven-autoscaling/). This release introduced a ton of features including support for multiple workloads (deployments & jobs), simplified deployment with Helm, documentation on [keda.sh](https://keda.sh/), and (my personal favorite) enterprise-class security with TriggerAuthentication CRD (which allows you to use pod identities such as Azure Managed Identity for pods). Over time our community has grown - More and more companies such as IBM, Pivotal, VMware, [Astronomer](https://www.astronomer.io/), and more started contributing to KEDA, we are collaborating with [Knative project](https://knative.dev/) to provide seamless integration with each other and our user base started growing with companies such as, [Purefacts](https://www.purefacts.com/), [SwissRe](https://www.swissre.com/) and more! We want to give KEDA more room to grow independently and ensure it has a vendor-agnostic focus. That's why on Jan 14, 2020, we proposed KEDA to the CNCF as a new Sandbox project. **Today, we are happy to announce that KEDA is now an [official CNCF Sandbox project](https://www.cncf.io/sandbox-projects/)!** By contributing KEDA to the CNCF we hope to ensure the adoption of KEDA continues to increase and hope to see more companies contribute scalers, integrate it in their products and give it a neutral home. This is a major step and I'm sure the best is yet to come. We would love to explicitly thank Liz Rice, Michelle Noorali & Xiang Lifor being our CNCF TOC sponsors and supporting KEDA as well as SIG-Runtime, especially Ricardo Aravena, for recommending us to TOC! So... what's next? In the near-term, we plan to focus on two major topics: Autoscaling HTTP workloads and scalers! Currently, we do not support HTTP-based autoscaling out-of-the-box, so we hope to create on a Service Mesh Interface (SMI) scaler for autoscaling service mesh workloads! In parallel, we have started plans for implementing add-on scalers. What are add-on scalers? We’re glad you've asked! Add-on scalers make it easy for users to define custom [external scalers](https://keda.sh/scalers/external/) without needing to contribute code to KEDA directly. One example of an external scaler is the [Azure Durable Function scaler](https://github.com/kedacore/keda-scaler-durable-functions). As this project evolves, our main focus will be to provide guidelines around when to add a scaler to the core and when to offer it as an external add-on. Next to that, we can create a centralized hub for all add-on scalers to improve discoverability similar to what [Helm Hub](https://hub.helm.sh/) provides. We have a lot of ideas and plans but we mainly are interested in what you want! Are you missing scalers, features or capabilities? Let us know! Thanks for reading, and happy scaling! KEDA Maintainers. ================================================ FILE: content/blog/2020-09-11-keda-2.0-beta.md ================================================ +++ title = "Give KEDA 2.0 (Beta) a test drive" date = 2020-09-11 author = "KEDA Maintainers" aliases = [ "/blog/keda-2.0-beta/" ] +++ Today, we are happy to share that our first **beta version of KEDA 2.0 is available**! 🎊 # Highlights With this release, we are shipping majority of our planned features. Here are some highlights: - **Making scaling more powerful** - Introduction of `ScaledJob` ([docs](https://keda.sh/docs/2.0/concepts/scaling-jobs/)) - Introduction of Azure Log Analytics scaler ([docs](https://keda.sh/docs/2.0/scalers/azure-log-analytics/)) - Support for scaling Deployments, Stateful Sets and/or any Custom Resources ([docs](https://keda.sh/docs/2.0/concepts/scaling-deployments/)) - Support for scaling on standard resource metrics (CPU/Memory) - Support for multiple triggers in a single `ScaledObject` ([docs](https://keda.sh/docs/2.0/concepts/scaling-deployments/)) - Support for scaling to original replica count after deleting `ScaledObject` ([docs](https://keda.sh/docs/2.0/concepts/scaling-deployments/)) - Support for controlling scaling behavior of underlying HPA - **Easier to operate KEDA** - Introduction of readiness and liveness probes - Introduction of Prometheus metrics for Metrics Server ([docs](https://keda.sh/docs/2.0/operate/)) - Provide more information when querying KEDA resources with `kubectl` - **Extensibility** - Introduction of External Push scaler ([docs](https://keda.sh/docs/2.0/scalers/external-push/)) - Introduction of Metric API scaler ([docs](https://keda.sh/docs/2.0/scalers/metrics-api/)) - Provide KEDA client-go library For a full list of changes, we highly recommend going through [our changelog](https://github.com/kedacore/keda/blob/v2/CHANGELOG.md#v200)! With our stable release, we'll provide a full overview of what's released in a new blog post. # Getting started Get started now, and install our beta with Helm: >`$ helm repo add kedacore https://kedacore.github.io/charts` >`$ kubectl create namespace keda` >`$ helm install keda kedacore/keda --namespace keda --version 2.0.0-beta1.2` As an alternative, you can use our deployment YAML: >`$ kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0-beta/keda-2.0.0-beta.yaml` # Migrating to KEDA 2.0 We want it to be super simple to use 2.0 as an existing customer! But what has changed? - API namespace for KEDA Custom Resources Definitions (CRD) has changed from `keda.k8s.io` to `keda.sh` - Scaling jobs is now done through `ScaledJob` CRD, instead of `ScaledObject` CRD - `ScaledObject` is now using `spec.scaleTargetRef.name`, instead of `spec.scaleTargetRef.deploymentName` - `ScaledObject` no longer requires `deploymentName` label _(last couple of v1 releases were already ignoring it)_ Learn more on how to migrate by using our [migration guide](https://keda.sh/docs/2.0/migration/)! With our official release we will provide [migration scripts](https://github.com/kedacore/keda/issues/946) allowing you to migrate your KEDA resources automatically. > **⚠ Running KEDA 1.x & 2.0 Beta side-by-side is not supported.** > > KEDA comes with a metrics server and Kubernetes only allows you to run one of them in a cluster. > >*Learn more about how KEDA is architected in [our docs](https://keda.sh/docs/concepts/#keda-architecture).* # Conclusion We are looking forward to hearing your feedback: - What do you like and/or what could be improved? - What issues did you find? - How can the migration be smoother? While we are eagerly waiting for feedback, we plan to release KEDA 2.0 stable around early September, 2020! Thanks for reading, and happy scaling! KEDA Maintainers. ================================================ FILE: content/blog/2020-11-04-keda-2.0-release.md ================================================ +++ title = "Announcing KEDA 2.0 - Taking app autoscaling to the next level" date = 2020-11-04 author = "KEDA Maintainers" aliases = [ "/blog/keda-2.0-release/" ] +++ A year ago, we were excited to **announce our 1.0 release with a core set of scalers**, allowing the community to start autoscaling Kubernetes deployments. We were thrilled with the response and encouraged to see many users leveraging KEDA for event driven and serverless scale within any Kubernetes cluster. With KEDA, any container can scale to zero and burst scale based directly on event source metrics. ![Logo](/img/logos/keda-horizontal-color.png) While KEDA was initially started by Microsoft & Red Hat **we have always strived to be an open & vendor-neutral project** in order to support everybody who wants to scale applications. That's why earlier this year we donated and were accepted as a CNCF Sandbox project. We feel this is a strong signal to the community to fully align with the CNCF open mindset and vendor neutrality. **Since KEDA 1.0 was released we’ve been growing** with new scalers for many different sources including IBM MQ, Postgres, and Huawei Cloudeye, supporting new authentication providers such as HashiCorp Vault, and constantly improving the user experience to make application auto scaling dead-simple. Today, we are happy to announce another milestone - **KEDA 2.0 is now generally available and ready to scale all your workloads!** 🎊 ## Getting started There are many ways to get started with KEDA: - Install with [OperatorHub.io](https://operatorhub.io/operator/keda) - Install with Helm: >$ helm repo add kedacore https://kedacore.github.io/charts > >$ kubectl create namespace keda > >$ helm install keda kedacore/keda --namespace keda --version 2.0.0 - Install with deployment YAML: > $ kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml Want to see it in action? Try one of [our samples](https://github.com/kedacore/samples#keda-20). ## What’s new? 🚀 KEDA 2.0 brings a ton of improvements and fixes. Please check the [changelog](https://github.com/kedacore/keda/blob/main/CHANGELOG.md#v200) to see the full list of changes and improvements in this release. There are two types of workloads that can be autoscaled in Kubernetes cluster: a deployment-like workload or job-like workload. KEDA 1.x supported scaling of both types by specifying it in the ScaledObject resource, and was limited to only scaling Kubernetes `Deployment` or `Jobs` resources. With KEDA 2.0 we have split both options and introduce a separate resource to describe both types, to better accommodate different needs for the configuration and behavior - **ScaledObject and ScaledJob resources**. KEDA 2.0 brings another long awaited feature, **you can specify multiple triggers on one ScaledObject/ScaledJob**, this way your workload can be autoscaled based on different triggers (eg. Kafka and Prometheus), KEDA will select the maximum value from the scalers to define the scaling decision, ie. the target number of replicas. ### ScaledObject improvements ScaledObject describes the specification for deployment-like workloads. And we are not talking just about `Kubernetes Deployments`, with **KEDA 2.0 you can scale `StatefulSets` or any other `CustomResource` that implements `/scale` subresource (eg. Argo Rollouts)**. This brings more scenarios and use cases that could benefit from KEDA and its autoscaling capabilities. Users can simply implement /scale endpoint on their Custom Resources and get autoscaling working out of the box! If you are running KEDA on Kubernetes version >= 1.18, you can benefit from configurable scaling behavior, which allows you to **specify the behavior for scaling up and down**. This exposes these new capabilities of the Kubernetes Horizontal Pod Autoscaler to KEDA. ### Introducing ScaledJob As mentioned earlier, KEDA 2.0 brings a separate custom resource for scaling of `Kubernetes Jobs`. This allows us to accommodate and simplify the specification and configuration, as scaling `Jobs` has different needs than scaling deployment-like workloads. Scaling Jobs can have different use cases and those could be even different with different scalers. That’s why ScalingStrategy for ScaledJobs was introduced in KEDA 2.0, which allows users to **select different strategies for scaling of Kubernetes Jobs**. ### New scalers KEDA 2.0 introduces **new scalers** for you to use. For starters, our community worked together to add **Azure Log Analytics & IBM MQ scalers**. By using our new CPU / Memory scaler you no longer have to mix & match Horizontal Pod Autoscalers (HPA) & ScaledObjects anymore - You can now **fully standardize on KEDA and we’ll handle all the HPAs for you!** With our new **external push scaler**, you can build your own scaler and **trigger scaling actions in KEDA by using a push-model for more reactive autoscaling**, instead of a pull-model with our current pull-based model in our external scaler. Finally, with our new **Metrics API scaler you can automatically scale on metrics provided through a REST API** without having to build your own scaler. This allows you to make autoscaling decisions based on a metric source that is available in your landscape (for example an in-house API or Microsoft Dynamics CRM API to automate processes). On top of these new scalers, we’ve made a variety of improvements to the current scalers to optimize our scaling. ### Operations & Extensibility KEDA now exposes **Liveness and Readiness probes** on both Operator and Metrics server pods, so administrators have a better overview of the state and health of KEDA. KEDA Metrics Server now **exposes Prometheus metrics about each used scaler**. Currently these metrics work with ScaledObject metrics when the HorizontalPodAutoscaler is active (> 0 replicas). In further releases of KEDA there are plans to extend this capability and serve metrics for ScaledJobs as well. Developers can now use a **go-client library** that is [exposed](https://github.com/kedacore/keda/tree/main/pkg/generated) to allow easy manipulation of the KEDA API from within applications. ## Migrating to KEDA 2.0 We want it to be super simple to use 2.0 as an existing customer! But what has changed? We’re making some general changes: - API namespace for KEDA Custom Resources Definitions (CRD) has changed from `keda.k8s.io` to `keda.sh` - Scaling jobs is now done through `ScaledJob` CRD, instead of `ScaledObject` CRD - `ScaledObject` is now using `spec.scaleTargetRef.name`, instead of `spec.scaleTargetRef.deploymentName` - `ScaledObject` no longer requires `deploymentName` label _(last couple of v1 releases were already ignoring it)_ In order to provide a more consistent experience across all scalers, we’re introducing improved flexibility & usability of trigger metadata for which we had to do some [cross-scaler breaking changes](https://keda.sh/docs/2.0/migration/#improved-flexibility--usability-of-trigger-metadata) as well as improvements for [Azure Service Bus, Kafka & RabbitMQ scalers](https://keda.sh/docs/2.0/migration/#scalers). Learn more about how to migrate by using our [migration guide](https://keda.sh/docs/2.0/migration/)! > **⚠ Running KEDA 1.x & 2.0 side-by-side is not supported.** > > KEDA comes with a metrics server and Kubernetes only allows you to run one of them in a cluster. > >*Learn more about how KEDA is architected in [our docs](https://keda.sh/docs/concepts/#keda-architecture).* ## KEDA 💘 Community **KEDA would not have been what it is today without our great community** - They have helped us shape our KEDA 2.0 release with their feature request, contributions, testing our release candidates and their support! It is wonderful to see how **more and more people from [across the globe](https://keda.devstats.cncf.io/d/50/countries-statistics-in-repository-groups?orgId=1&var-period_name=Quarter&var-countries=All&var-repogroup_name=All&var-metric=contributions&var-cum=countries) start to contribute back** from companies such as IBM, Oracle, Pivotal, Polidea, Tripadvisor, VMWare, Zapier and [so many more](https://keda.devstats.cncf.io/d/4/company-statistics-by-repository-group?orgId=1&var-period=m&var-metric=activity&var-repogroup_name=All&var-companies=All) - We could not have done this without them! We’re honored to see other technologies adopting KEDA to use in their own products, here are a few of them: - **Apache Airflow & Astronomer** are using KEDA to autoscale workflows. ([blog post](https://www.astronomer.io/blog/the-keda-autoscaler/)) - **Dapr** is recommending KEDA to autoscale Dapr apps ([walkthrough](https://docs.dapr.io/developing-applications/integrations/autoscale-keda/) & [sample](https://github.com/dapr/samples/blob/master/functions-and-keda/README.md)) - **Fission** is building a catalog of KEDA connectors to scale their serverless functions on Kubernetes ([GitHub](https://github.com/fission/keda-connectors)) - **Knative** is using KEDA to autoscale Knative Event Sources ([GitHub](https://github.com/knative-sandbox/eventing-autoscaler-keda)) We are super thankful that these companies and technologies have adopted KEDA: {{< user-icons >}} Another user of KEDA is Alibaba Cloud who has adopted KEDA for all their autoscaling: > “Alibaba's [Enterprise Distributed Application Service (EDAS)](https://www.alibabacloud.com/product/edas) which is built with [KubeVela](https://github.com/oam-dev/kubevela/) project adopts KEDA as the implementation for its auto-scaling trait (see: [trait system of Open Application Model](https://github.com/oam-dev/spec/blob/master/6.traits.md)) from mid of 2020. In Alibaba, EDAS has served more than 1000+ applications from both Alibaba Cloud's customers and internal scenarios. EDAS's KEDA based auto-scaling trait uses Alibaba's ARMS (i.e. Application Real-Time Monitoring Service) as the trigger by default, and it's also under integration with AIOps system of EDAS for advanced scenarios such as capacity diagnose based auto-scaling.” > > -- *Yan Xun, Senior Engineer of Alibaba Cloud* Are you using KEDA in production as well? Don’t hesitate and [let us know](https://github.com/kedacore/keda#become-a-listed-keda-user)! ## Looking ahead 🧭 We’ve been working on this milestone for a while and are happy to finally be able to officially release KEDA 2.0! But we’re not stopping there and have already started working on v2.1. Transparency is essential to become a successful open-source project and we want to be open on the future of KEDA. Because of that, we’re introducing a **public high-level roadmap of KEDA** ([link](https://github.com/kedacore/keda/projects/3)) allowing you to get an idea of where we are going with the project and allow you to provide suggestions so we can adapt. Next, we are going to **further improve KEDA as a project and focus on making it more robust** by introducing a security policy, automated vulnerability scanning, and such to ensure we are shipping secure software so that you don’t have to worry about it. As KEDA continues to grow, many organizations have contributed back and shared a number of very interesting use cases that rely on KEDA. We are working on writing a reference case to show the value of KEDA for customers. As we continue to work with the community, our goal is to **propose to graduate to CNCF Incubation** ([issue](https://github.com/kedacore/keda/issues/1143)) **later this year / early next year**. Any support we can get from the community will be extremely helpful as we move to make the next steps in bringing the benefits of KEDA to every user. Last but not least, we want people to be able to show their support for KEDA and are working on **providing merchandise** that you can purchase which you can wear with pride! Sit back and wait for our swag to show up. Thanks for reading, and happy scaling! KEDA Maintainers. ================================================ FILE: content/blog/2021-03-26-migrating-to-github-container-registry.md ================================================ +++ title = "Migrating our container images to GitHub Container Registry" date = 2021-03-26 author = "KEDA Maintainers" aliases = [ "/blog/migrating-to-github-container-registry/" ] +++ We provide **various ways to [deploy KEDA](https://keda.sh/docs/latest/deploy/) in your cluster** including by using [Helm chart](https://github.com/kedacore/charts), [Operator Hub](https://operatorhub.io/operator/keda) and raw YAML specifications. These deployment options all rely on the container images that we provide which are available on **[Docker Hub](https://hub.docker.com/u/kedacore), the industry standard for public container images**. However, we have found that Docker Hub is no longer the best place for our container images and are migrating to GitHub Container Registry (Preview). ## Why are making this change? ### Docker Hub is introducing rate limiting and image retention Over the past couple of years, Docker Hub has become the industry standard for hosting public container images. This has become a big burden for Docker to manage all the traffic and decided in 2020 to make some changes: - Anonymous image pulls are being rate limited - Unused images will no longer be retained Because we want to ensure that our end-users can use KEDA without any issues, we want to make them available to anyone without any limitations. Learn more about these changes in [Docker's FAQ](https://www.docker.com/pricing/resource-consumption-updates) and our issue on [GitHub](https://github.com/kedacore/keda/issues/995). ### Gaining insights on KEDA adoption As maintainers, **we find it hard to measure the adoption of KEDA** to understand how many end-users are using older versions of KEDA and what the growth is over time. Docker Hub provides a vague total pull count per container image, but it does not give in-depth details concerning the tags and what the pull growth is over time. In GitHub Container Registry, however, **metrics are provided out-of-the-box on a per-tag basis** allowing us to better understand what our customers are using and make better decisions when we no longer support a given version. ### Bringing our artifacts closer to home Lastly, we want to **bring our artifacts closer to our home on GitHub**. By using more of the GitHub ecosystem, we believe that this integration will only improve and get tighter integration with our releases and such. ## What is changing? Our container images are being published on [GitHub Container Registry](https://github.com/orgs/kedacore/packages?type=source) for end-users to pull them. Because of this, the names of our container images are changing: | Component | New Image (GitHub Container Registry) | Legacy Image (Docker Hub) | | :------------- | :---------------------------------------- | --------------------------------- | | Metrics Server | `ghcr.io/kedacore/keda-metrics-apiserver` | `kedacore/keda-metrics-apiserver` | | Operator | `ghcr.io/kedacore/keda` | `kedacore/keda` | ## When is this taking place? As of v2.2, we have started publishing our new container images to GitHub Container Registry in parallel to Docker Hub. This allows customers to already migrate to our new registry and consume our artifacts there. **Once GitHub Container Registry becomes generally available (GA), we will no longer publish new versions to Docker Hub.** ## What is the impact for end-users? **If you are using one of our deployment options, end-users are not be impacted.** Since v2.2, we are using GitHub Container Registry by default and you are good to go. If you are using your own deployment mechanism, then you will have to pull the container images from GitHub Container Registry instead. ## Join the conversation Do you have questions or remarks? Feel free to join the conversation on [GitHub Discussions](https://github.com/kedacore/keda/discussions/1700). Thanks for reading, and happy scaling! KEDA Maintainers. ================================================ FILE: content/blog/2021-04-06-why-alibaba-cloud-uses-keda-for-app-autoscaling.md ================================================ +++ title = "Why Alibaba Cloud uses KEDA for application autoscaling" date = 2021-04-06 author = "Yan Xun, Andy Shi, and Tom Kerkhove" aliases = [ "/blog/why-alibaba-cloud-uses-keda-for-app-autoscaling/" ] +++ > This blog post was initially posted on [CNCF blog](https://www.cncf.io/blog/2021/03/30/why-alibaba-cloud-uses-keda-for-application-autoscaling/) and is co-authored by Yan Xun, Senior Engineer from Alibaba Cloud EDAS team & Andy Shi, Developer Advocator from Alibaba Cloud. When scaling Kubernetes there are a few areas that come to mind, but if you are new to Kubernetes this can be a bit overwhelming. In this blog post; we will briefly explain the areas that need to be considered, how KEDA aims to make application auto-scaling simple, and why Alibaba Cloud’s [Enterprise Distributed Application Service (EDAS)](https://www.alibabacloud.com/product/edas) has fully standardized on KEDA. ## An introduction to scaling Kubernetes When managing Kubernetes clusters & applications, you need to carefully monitor a variety of things such as : - **Cluster capacity** – Do we have enough resources available to run our workloads? - **App Workload** – Does the application have enough resources available? Can it keep up with the pending work (ie. queue depth) In order to automate this, you’d typically set up alerts to get notified or even use auto-scaling. Kubernetes is a great platform and helps you with this out-of-the-box. **Scaling your cluster** can be easily done by using the **Cluster Autoscaler** component that will monitor your cluster for pods that are unable to be scheduled due to resource starvation and start adding/removing nodes accordingly. Since Cluster Autoscaler only kicks in when your pods are over-scheduled, you may have a time gap during which your workloads are not up and running. **Virtual Kubelet**, a CNCF sandbox project, is a tremendous help that allows you to add a “virtual node” to your Kubernetes cluster on which pods can be scheduled. ![Virtual Kubelet](/img/blog/alibaba-cloud-ref-case/virtual-kubelet.png) By doing this, platform providers (such as Alibaba, Azure, HashiCorp and [others](https://github.com/virtual-kubelet/virtual-kubelet#providers)) allow you to **overflow your pending pods outside of your cluster until it provides the required cluster capacity to mitigate this issue**. In addition to scaling the cluster, Kubernetes allows you to easily **scale your application**: - Horizontal Pod Autoscaler ([HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)) allows you to add/remove more pods to your workloads to scale in/out (adding or removing replicas) - Vertical Pod Autoscaler ([VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)) allows you to add/remove resources to your pods to scale up/down (adding or removing CPU or memoru) All of this combined gives you a very good starting point to scale your application. ## The limitations of Horizontal Pod Autoscaler (HPA) While the HPA is a great place to start, it is mainly focused on metrics of the pods themselves allowing you to scale it based on CPU & memory. That said, you can fully configure how it should be autoscaled which makes it powerful. While that is ideal for some workloads, you’d typically want to scale on metrics that are available somewhere else such as Prometheus, Kafka, a cloud provider, or other events. Thanks to the [external metric support](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-external-metrics.md), users can install metric adapters that serve a variety of metrics from external services and make them available to autoscale on by using a metric server. There is one caveat, though, you can only run one metric server inside your cluster which means that you’ll have to choose where your custom metrics come from. ![Standard App Autoscaling](/img/blog/alibaba-cloud-ref-case/vanilla-autoscaling.png) You could use Prometheus and use tools, such as Promitor, to bring your metrics from other providers and use that as a single-source-of-truth to scale on but that requires a lot of plumbing and work to scale. There must be a simpler way… Yes, use Kubernetes Event-Driven Autoscaling (KEDA)! ## What is Kubernetes Event-Driven Autoscaling (KEDA)? Kubernetes Event-Driven Autoscaling (KEDA) is a single-purpose event-driven autoscaler for Kubernetes that can be easily added to your Kubernetes cluster to scale your applications. It aims to make application auto-scaling dead-simple and optimize for cost by supporting scale-to-zero. KEDA takes away all the scaling infrastructure and manages everything for you, allowing you to scale on 30+ systems or extend it with your own scalers. Users only need to create a ScaledObject or ScaledJob that defines what you want to scale and what triggers you want to use; KEDA will handle all the rest! ![App Autoscaling with KEDA](/img/blog/alibaba-cloud-ref-case/keda-autoscaling.png) And you can literally scale anything; even if it’s a CRD from another tool you are using, as long as it implements /scale subresource. So, does KEDA reinvent the wheel? No! Instead, it extends Kubernetes by using HPAs under the hood that use our external metrics which are served from our own metrics adapter that replaces all the other adapters. ![KEDA Architecture](/img/blog/alibaba-cloud-ref-case/architecture.png) Last year, KEDA joined the CNCF as CNCF Sandbox project and is planning to propose to graduate to Incubation later this year. ## Introduce Alibaba’s practice based on OAM/KubeVela and KEDA As the major enterprise PaaS offering on Alibaba Cloud, [Enterprise Distributed Application Service (EDAS)](https://www.alibabacloud.com/product/edas) has been serving countless developers on the public cloud with massive scale for years. From an architectural perspective, EDAS is built with the [KubeVela project](https://kubevela.io/). Its overall architecture is like the below. ![EDAS Overview](/img/blog/alibaba-cloud-ref-case/edas-overview.png) In production, EDAS integrated ARMS monitoring service on Alibaba Cloud to provide monitoring and fine-grained metrics of the application. EDAS team added an ARMS Scaler to the KEDA project to perform autoscaling. They also added a couple of features and fixed some bugs in the KEDA v1 release. Including: - When there are multiple Triggers, the values will be summed up rather than leaving them as individual values. - When creating KEDA HPA, the length of the name will be limited to 63 characters to avoid triggering DNS complaints. - Triggers can not be disabled and this might cause trouble in production. EDAS team is actively working on sending these fixes to KEDA upstream, though some of them have already been added to the V2 release. ## Why Alibaba Cloud standardized on KEDA as their application autoscaler When it comes to auto-scaling features, EDAS originally used the upstream Kubernetes HPA with the CPU and Memory as the two metrics in the beginning. However, as the user base grows and requirement diversifies, the EDAS team soon found the limitations of the upstream HPA: 1. **Limited support for customized metrics, especially for application-level fine-grained metrics** The upstream HPA focuses on the container level metrics, such as CPU and Memory, which is too coarse for the applications. Metrics that reflect the application loads, such as RT and QPS are not supported out of the box. Yes, HPA can be extended. However, that capability is limited when it comes to application-level metrics. EDAS team was often forced to fork code when trying to introduce fine-grained application-level metrics. 2. **No support for scale-to-zero** Many users have the requirement of Scale to Zero when their microservices are not being consumed. This requirement is not limited just to FaaS/Serverless workloads. It saves costs and resources for all users. Currently, upstream HPA doesn’t support this feature. 3. **No support for scheduled scaling** Another strong requirement from the EDAS users is the scheduled scaling capability. Again, upstream HPA doesn’t provide this feature, and the EDAS team needs to look for non-vendor lock alternatives. Based on those requirements, the EDAS team started planning the new version of EDAS auto-scaling feature. In the meantime, EDAS went through an overhaul of its underlying core components by introducing OAM at the beginning of 2020. OAM gives EDAS the standardized, pluggable application definition to replace its in-house Kubernetes Application CRD. And the extensibility of this model makes it possible for EDAS to integrate with any new capability from the Kubernetes community with ease. In that context, the EDAS team tried to align the need for new auto-scaling features for EDAS with looking for a standard implementation for OAM’s autoscaling trait. Base on the use cases, the EDAS team summarized three criteria: 1. The auto-scaling feature should present itself as a simple atomic capability without attachment to any complex solutions. 2. The metrics should be pluggable, so the EDAS team can customize it and build on top of it to support various requirements. 3. It should support Scale to Zero out of the box. After detailed evaluation, the EDAS team picked the project KEDA, which was open-sourced by Microsoft & Red Hat and has been donated to CNCF. KEDA has several useful Scalers that come by default and supports Scale to Zero out of the box. It provides fine-grained auto scaling for applications. It has the concept of Scalar and Metrics adapter, which enables powerful plugin architecture while providing a unified API layer. Most importantly, the design of KEDA focuses on autoscaling only so it can be integrated as an OAM trait at ease. Overall, KEDA is a good fit for EDAS. ## Looking Ahead As the next step, Alibaba is actively working on making KEDA trait driven by AIOps, with the goal to bring intelligent decision making to its autoscaling behavior. This will essentially enable autoscaling decisions based on expert system and historical data analysis with leverage of newly implemented application QoS trigger and database metrics trigger etc in Alibaba’s KEDA components. Thus, we will expect a more powerful, intelligent, and stable KEDA based auto-scaling capability will be shipped in KEDA soon. ================================================ FILE: content/blog/2021-05-27-azure-pipelines-scaler.md ================================================ +++ title = "Autoscaling Azure Pipelines agents with KEDA" date = 2021-05-27 author = "Troy Denorme" +++ With the addition of Azure Piplines support in KEDA, it is now possible to autoscale your Azure Pipelines agents based on the agent pool queue length. Self-hosted Azure Pipelines agents are the perfect workload for this scaler. By autoscaling the agents you can create a scalable CI/CD environment. > 💡 The number of concurrent pipelines you can run is limited by your [parallel jobs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents#parallel-jobs). > > KEDA will autoscale to the maximum defined in the ScaledObject and does not limit itself to the parallel jobs count defined for the Azure DevOps organization. ## What are Azure Pipelines self-hosted agents? Azure Pipelines jobs can run on different kinds of agents ([docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents)). But if you want full control, you are going to have to use self-hosted agents. Agents are able to run on Linux, macOS or Windows machines and can be packaged in to a container. When running self-hosted agents on Kubernetes, there is no out-of-the-box support for autoscaling. However, with KEDA v2.3 you can now autoscale your self-hosted agents on Kubernetes based on the amount of pending jobs in your agent pool. You can run the agents as a `Deployment` or a `Job` in Kubernetes and scale them accordingly with a `ScaledObject` or a `ScaledJob`. ## Deploying a self-hosted agent on Kubernetes as a Deployment ### Create the container image To create a basic Azure Pipelines agent image you can follow the instructions from [the official docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker#linux). ### Deploy on Kubernetes You can easily deploy the agent as a Kubernetes deployment by using this Kubernetes manifest: ```yaml apiVersion: v1 kind: Secret metadata: name: azdevops data: AZP_TOKEN: --- apiVersion: apps/v1 kind: Deployment metadata: name: azdevops-deployment labels: app: azdevops-agent spec: replicas: 1 selector: matchLabels: app: azdevops-agent template: metadata: labels: app: azdevops-agent spec: containers: - name: azdevops-agent image: env: - name: AZP_URL value: "https://dev.azure.com/" - name: AZP_POOL value: "" - name: AZP_TOKEN valueFrom: secretKeyRef: name: azdevops key: AZP_TOKEN volumeMounts: - mountPath: /var/run/docker.sock name: docker-volume volumes: - name: docker-volume hostPath: path: /var/run/docker.sock ``` ### Autoscaling with KEDA After the deployment is created you need to create the `ScaledObject` in order for KEDA to start scaling the deployment. To scale based on the queue length of an Azure Pipelines agent pool, you can use the `azure-pipelines` trigger as of KEDA v2.3. ```yaml apiVersion: v1 kind: Secret metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" authenticationRef: name: pipeline-trigger-auth ``` The default `targetPipelinesQueueLength` is `1`, so there will be one agent for each job. > ⚠ The Azure Pipelines scaler supports scaling to zero but you need at least one agent registered in the agent pool in order for new jobs to be scheduled on the pool. ### Running Azure Pipelines jobs After deploying the agent and the KEDA `ScaledObject` it is time to see the autoscaling in action. First, check the current pods running in the deployment: ```sh $ kubectl get pods NAME READY STATUS RESTARTS AGE azdevops-deployment-5854bbbf84-r86qv 1/1 Running 0 75s ``` ![deployment agents](/img/blog/azure-pipelines-scaler/deployment-agents.png) Now let's queue some builds. ![azure devops builds](/img/blog/azure-pipelines-scaler/deployment-builds.png) As a result, you see that KEDA starts scaling out the pods to meet the pending jobs: ```sh $ kubectl get pods NAME READY STATUS RESTARTS AGE azdevops-deployment-5854bbbf84-4gfbx 1/1 Running 0 36s azdevops-deployment-5854bbbf84-r86qv 1/1 Running 0 12m azdevops-deployment-5854bbbf84-tm47k 1/1 Running 0 36s ``` And they appear on Azure Pipelines as well: ![deployment agents](/img/blog/azure-pipelines-scaler/deployment-agents-autoscaled.png) ## Run the self-hosted agent as a Job When running your agents as a deployment you have no control on which pod gets killed when scaling down. ([see KEDA docs](https://keda.sh/docs/1.4/concepts/scaling-deployments/#long-running-executions)) If you run your agents as a `Job`, KEDA will start a Kubernetes job for each job that is in the agent pool queue. The agents will accept one job when they are started and terminate afterwards. Since an agent is always created for every pipeline job, you can achieve fully isolated build environments by using Kubernetes jobs. The following manifest is an example of a `ScaledJob` combined with the Azure Pipelines agent. You have to use a modified image for this where the agent terminates itself after running a job. ([docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux#run-once)) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: azdevops-scaledjob spec: jobTargetRef: template: spec: containers: - name: azdevops-agent-job image: imagePullPolicy: Always env: - name: AZP_URL value: "" - name: AZP_TOKEN value: "" - name: AZP_POOL value: "" volumeMounts: - mountPath: /var/run/docker.sock name: docker-volume volumes: - name: docker-volume hostPath: path: /var/run/docker.sock pollingInterval: 30 successfulJobsHistoryLimit: 5 failedJobsHistoryLimit: 5 maxReplicaCount: 10 scalingStrategy: strategy: "default" triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" personalAccessTokenFromEnv: "AZP_TOKEN" ``` ### Placeholder agent You cannot queue an Azure Pipelines job on an empty agent pool because Azure Pipelines cannot validate if the pool matches the requirements for the job. When you try to do this you will encounter the following error: > ##[error]No agent found in pool keda-demo which satisfies the specified demands: Agent.Version -gtVersion 2.163.1 You can, however, use a workaround to register an agent as a placeholder which allows you to queue jobs on an agent pool that has no agents that are online. Make sure you don't execute any cleanup code in your container to unregister the agent when removing it to keep the placeholder agent registered in the agent pool. ### Seeing `ScaledJobs` in action To allow scaling to zero and create agents on-demand, a template agent was created as a placeholder to be able to queue jobs. ![placeholder agent](/img/blog/azure-pipelines-scaler/placeholder-agent.png) Now, let's queue some pipelines: ![azure devops builds](/img/blog/azure-pipelines-scaler/jobs-builds.png) KEDA will create a Kubernetes job for each pending job in the queue for the specified agent pool. ```sh $ kubectl get pods NAME READY STATUS RESTARTS AGE azdevops-scaledjob-2hshf-mp5jl 1/1 Running 0 24s azdevops-scaledjob-5gzr5-p8625 1/1 Running 0 24s azdevops-scaledjob-mmlzc-rw5gm 1/1 Running 0 24s ``` Once that happens, you will see the agents are starting to process the pending Azure Pipelines jobs: Once that happens, you will see the jobs in the Azure Pipelines' agent pool: ![scaledjobs agents](/img/blog/azure-pipelines-scaler/jobs-agents-autoscaled.png) Using a `ScaledJob` is the preferred way to autoscale your Azure Pipelines agents if you have long-running jobs. The other option is using a `deployment` and leveraging the container lifecycle. ([docs](https://keda.sh/docs/1.4/concepts/scaling-deployments/#leverage-the-container-lifecycle)) ================================================ FILE: content/blog/2021-06-24-announcing-http-add-on.md ================================================ +++ title = "Announcing KEDA HTTP Add-on v0.1.0" date = 2021-06-24 author = "Aaron Schlesinger and Tom Kerkhove" +++ Over the past few months, we’ve been adding more and more scalers to KEDA making it easier for users to scale on what they need. Today, we leverage more than 30 scalers out-of-the-box, supporting all major cloud providers & industry-standard tools such as Prometheus that can scale any Kubernetes resource. But, we are missing a major feature that many modern, distributed applications need - the ability to scale based on HTTP traffic. It’s time to change this. >Note: You can build your own custom HTTP autoscaling system using the [Prometheus scaler](https://keda.sh/docs/2.2/scalers/prometheus/) per our FAQ. The new HTTP Addon adds first-class, end-to-end support for HTTP. ## Introducing our HTTP add-on for KEDA Autoscaling HTTP is often not as straightforward as other event sources. You don't know how much traffic will be coming and, given its synchronous nature, supporting scale-to-zero HTTP applications requires an intelligent intermediate routing layer to “hold” the incoming request(s) until new instances of the backend application are created and running. We’re happy to announce our experimental HTTP add-on for KEDA which is purely focused on solving this problem. This new project introduces an `HTTPScaledObject` CRD, which you use to autoscale a Kubernetes `Deployment`, including scale-to-zero. We’ve taken a “batteries included with reasonable defaults” approach to designing and building the HTTP add-on. This means that you don’t have to run other tools such as Prometheus. At the same time, the system is made up of well-defined, reusable components that can run independently. You can opt-out of the defaults and customize components as you see fit. In many cases, you can even run most of the components independently. Scaling based on incoming HTTP traffic is different from core KEDA triggers for two reasons: - There is no standard existing API you can call to get a counter or other metric to scale on. For example, we cannot call the Kafka API to get the length of a queue. - You need to set up the infrastructure to route HTTP requests to the server you’re autoscaling You can see the HTTP add-on as just another trigger in your scaling toolbox. ⚠ Given its experimental state of this project, breaking changes can occur and the HTTP add-on is not supported for production workloads yet. ### How does it work? Since KEDA already does an excellent job listening for events and autoscaling, the HTTP add-on simply adds an HTTP-aware layer on top. The system is made up of 3 components: - **Interceptor**: This component accepts HTTP requests into the system, reports pending HTTP request queue metrics to the external scaler, and forwards requests to the target application. - If the application is currently scaled to zero replicas, the interceptor will hold requests until it scales up - **External scaler**: This is an [external push scaler](https://keda.sh/docs/2.1/scalers/external-push/) that constantly pings the interceptor to get pending HTTP queue metrics. It transforms these data and sends them directly down to KEDA, which then makes a scaling decision - **Operator**: This is an [Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) that runs for the convenience of the user. It listens for new [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) resources, called `HTTPScaledObject`s, and creates and configures interceptors and scalers so that your existing [`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) will begin autoscaling according to incoming HTTP traffic. ![architecture diagram](/img/blog/http-add-on/arch.png) ## Seeing it in action We’ve aimed to make the HTTP add-on approximately as simple to operate and use as KEDA. There are two major steps to using it: 1. Install the KEDA HTTP add-on operator 2. Create a new `HTTPScaledObject` ### Installing the Operator This is an optional step, but we highly recommend it because the operator makes interacting with the HTTP add-on more convenient. We’ve packaged the operator up in a [Helm](https://helm.sh) chart, which you can install by following the instructions below. _The commands below have been tested on Mac and Linux (Ubuntu). They likely work on Windows WSL2, but won’t work on Powershell. You’ll also need to ensure you have access to a Kubernetes cluster with a Kubernetes configuration file properly configured._ #### Install KEDA First, make sure you’ve set up an environment variable for the namespace you’d like to install everything into: ```shell export NAMESPACE=mynamespace ``` Next, install KEDA: ```shell helm repo add kedacore https://kedacore.github.io/charts helm repo update helm install --create-namespace -n ${NAMESPACE} keda kedacore/keda ``` #### Install the Operator Now that KEDA is installed, you can install the operator: ```shell helm install --create-namespace -n ${NAMESPACE} http-add-on kedacore/keda-add-ons-http ``` ### Install an `HTTPScaledObject` The `HTTPScaledObject` CRD instructs the operator to install and configure the interceptor and scaler for a specified `Deployment`. For this to work, you’ll need to have a Deployment running in the same `$NAMESPACE` and a Service configured to route traffic to the pods in that `Deployment`. >We've created a sample application [here](https://github.com/kedacore/http-add-on/tree/main/examples/xkcd) as a Helm chart for you. It comes complete with a properly configured `HTTPScaledObject`, so when you install the chart, everything will be automatically configured for you and you can skip the rest of this section. If you install this chart, you can skip the rest of this section. After you have your application set up, copy the following YAML into a file called myautoscaledapp.yaml: ```yaml kind: HTTPScaledObject apiVersion: http.keda.sh/v1alpha1 metadata: name: myapp spec: scaleTargetRef: deployment: myAppDeployment service: myAppService port: 8080 ``` And finally, submit it to your Kubernetes cluster: ```shell kubectl create -f -n $NAMESPACE myautoscaledapp.yaml ``` The operator will pick up the CRD and, when it’s done installing and configuring, you’ll see a new `Service` (among other things!) that’s ready to route HTTP traffic to your Deployment. Send all of your HTTP to the Service, and the Deployment will begin autoscaling! ### Cleaning up To clean up, remove the HTTPScaledObject you created, then delete the two Helm charts you installed: ```shell kubectl delete -n $NAMESPACE httpscaledobject myapp helm delete -n ${NAMESPACE} kedahttp helm delete -n ${NAMESPACE} keda ``` ## What's next? With this release, we've built a solid foundation and are now focusing on testing, quality, and expanding the feature set appropriately. We encourage you to try the software out in your own non-production Kubernetes clusters and share feedback on what you think and we are open to contributions to make it even better. Today we support autoscaling any HTTP traffic sent to a Kubernetes Services, but we are planning to support more specific traffic patterns including “north-south” with `Ingress` or the [Gateway API](https://github.com/kedacore/http-add-on/issues/33) and “east-west” with service-to-service communication or [service meshes](https://github.com/kedacore/http-add-on/issues/6). In order to achieve this, we are working with the community to support as many existing products that exist today. For example, we will fully rely on the [Service Mesh Interface (SMI)](https://smi-spec.io/) specification which has become a solid industry standard for service-mesh workloads. But why stop there? We are talking to various SIGs to determine if we need a general Traffic Metrics specification that takes the learnings from SMI spec and apply it to all traffic components for a unified traffic metrics approach in Kubernetes. We’re also looking for feedback and contributors! Please feel free to [submit suggestions](https://github.com/kedacore/http-add-on/discussions/new) or [ask questions](https://github.com/kedacore/http-add-on/discussions/new), and if you’re interested in contributing, see our [contributing documentation](https://github.com/kedacore/http-add-on/blob/main/docs/contributing.md). Lastly, we’d like to thank the following folks for building the initial prototype of the HTTP add-on and creating this project: - [Aaron Schlesinger](https://github.com/arschles) - [Lucas Santos](https://github.com/khaosdoctor) - [Aaron Wislang](https://github.com/asw101) - [Tom Kerkhove](https://github.com/tomkerkhove/) and the rest of the [KEDA core Maintainers](https://github.com/orgs/kedacore/teams/keda-maintainers) Thanks for reading, Aaron Schlesinger on behalf of the KEDA HTTP Add-on contributors and KEDA maintainers. ================================================ FILE: content/blog/2021-08-04-keda-cast-ai.md ================================================ +++ title = "How CAST AI uses KEDA for Kubernetes autoscaling" date = 2021-08-04 author = "Žilvinas Urbonas (CAST AI), Annie Talvasto (CAST AI), and Tom Kerkhove (KEDA)" aliases = [ "/blog/how-cast-ai-uses-keda-for-kubernetes-autoscaling/" ] +++ # How CAST AI uses KEDA for Kubernetes autoscaling Kubernetes comes with several built-in [autoscaling mechanisms](https://cast.ai/blog/guide-to-kubernetes-autoscaling-for-cloud-cost-optimization/) - among them the Horizontal Pod Autoscaler (HPA). Scaling is essential for the producer-consumer workflow, a common use case in the IT world today. It’s especially useful for monthly reports and transactions with a huge load where teams need to spin up many workloads to process things faster and cheaper (for example, by using spot instances). Based on the provided CPU and memory-based metrics, the HPA can scale a setup up by adding more replicas - or down by removing idle replicas (this mechanism is called in/out). But it doesn’t have access to a source of metrics by default. The default HPA features aren’t flexible enough to cover custom scenarios like the producer/consumer. This is where KEDA comes in. Optimizing Kubernetes workloads for cost efficiency is the core mission of CAST AI. The platform helps teams reduce their cloud bills by up to 50% with no extra DevOps effort by automatically selecting optimal instances for running clusters, using spot instances whenever possible, and - of course - autoscaling with the help of KEDA. By automating routine DevOps tasks via Terraform or CLI, CAST AI saves teams many hours they would spend on researching, installing, maintaining, patching, and observing their Kubernetes infrastructure. It also helps to prevent downtime with its multi-cloud capabilities. ## KEDA & Horizontal Pod Autoscaler KEDA is available as a Policy/Add-on for clusters running in CAST AI. Users can easily install it by enabling the Horizontal Pod Autoscaler (HPA) policy in the console’s interface. KEDA includes two components: - operator - it watches Kubernetes for ScaledObject resources and configures the HPA accordingly, - metrics-apiserver - this is a bridge between Kubernetes and various scaling sources (including Prometheus). These two components configure the HPA and set up custom metric sources, helping teams to autoscale almost any workload: Deployment, ReplicaSet, ReplicationController, or StatefulSet. KEDA supports autoscaling Jobs too. ## Enabling KEDA in CAST AI To autoscale with the Horizontal Pod Autoscaler, users need to enable the KEDA add-on on the Policies page available for every cluster in CAST AI. ![CAST AI KEDA Policies](/img/blog/cast-ai-ref-case/cast-ai-keda-1.png "Tom's title") Once enabled, KEDA will start working on a given cluster once users configure the associated scaled object. KEDA automatically changes pod replica counts based on the provided metrics. ## Use case 1: Autoscaling based on CPU and/or Memory usage Let’s imagine that a user created a Deployment and a Service that they want to autoscale. ```yml apiVersion: apps/v1 kind: Deployment metadata: name: sample-app labels: app: sample-app spec: # Note that we omit the replica count so # when we redeploy, we wouldn't override # replica count set by the autoscaler #replicas: 1 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: containers: - image: luxas/autoscale-demo:v0.1.2 name: sample-app ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: sample-app labels: app: sample-app spec: ports: - port: 8080 name: http targetPort: 8080 protocol: TCP selector: app: sample-app ``` Note that the user doesn’t specify a particular ReplicaCount. Now it’s time to set up a [CPU-based Autoscaler](https://keda.sh/docs/latest/scalers/cpu/): ```yml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: sample-app spec: scaleTargetRef: name: sample-app minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 10 # Optional. Default: 100 triggers: # Either of the triggers can be omitted. - type: cpu metadata: # Possible values: `Value`, `Utilization`, or `AverageValue`. # More info at: https://keda.sh/docs/latest/scalers/cpu/#trigger-specification type: "Value" value: "30" - type: memory metadata: # Possible values: `Value`, `Utilization`, or `AverageValue`. # More info at: https://keda.sh/docs/latest/scalers/memory/ type: "Value" value: "512" ``` Deployment autoscaling will be triggered by CPU or Memory usage. Users can specify any other trigger or remove the triggers altogether - for example, to autoscale only on the basis of the CPU or only using the Memory trigger. ## Use case 2: Autoscaling based on a Prometheus metric CAST AI users can also autoscale their clusters based on the results of arbitrary Prometheus queries. CAST AI clusters come with Prometheus deployed out-of-the-box. So, let’s deploy a sample application again - but this time, we’ll instruct Prometheus to scrape some metrics: ```yml apiVersion: apps/v1 kind: Deployment metadata: name: sample-app labels: app: sample-app spec: selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app annotations: # These annotations the main difference! prometheus.io/path: "/metrics" prometheus.io/port: "8080" prometheus.io/scrape: "true" spec: containers: - image: luxas/autoscale-demo:v0.1.2 name: sample-app ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: sample-app labels: app: sample-app spec: ports: - port: 8080 name: http targetPort: 8080 protocol: TCP selector: app: sample-app ``` Then the user can deploy the Autoscaler. ```yml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: sample-app spec: scaleTargetRef: name: sample-app minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: prometheus metadata: serverAddress: http://prom.castai:9090 threshold: '1' # Note: query must return a vector/scalar single element response query: sum(rate(http_requests_total{app="sample-app"}[2m])) ``` Let’s check whether it all works by generating some load. You can see how the replica count increases. ```bash # Deploy busybox image kubectl run -it --rm load-generator --image=busybox /bin/sh # Hit ENTER for command prompt # trigger infinite requests to the php-apache server while true; do wget -q -O- http://sample-app:8080/metrics; done # in order to cancel, hold CTRL+C # in order to quit, initiate CTRL+D sequence ``` ## Batch processing with spot instances & KEDA Let’s go back to the producer-consumer problem we talked about earlier. Imagine that your company needs to process a large set of invoices at the end of each month. Your team has to spin up many workloads to process these jobs faster. You switch on the Pod Autoscaler policy and then turn to the KEDA configuration. ![CAST AI KEDA Policies](/img/blog/cast-ai-ref-case/cast-ai-keda-1.png) Note: The KEDA-based setup can also be used with CAST AI’s cluster autoscaler and spot instances to scale compute-intensive workloads in a cost-effective way. This is done by enabling the Unschedulable pods and Spot Instances policies. By enabling the node deletion policy, users ensure that idle instances are removed immediately. The policy settings above will help to achieve cost savings for workloads like batch data processing. By moving data processing jobs to spot instances, teams can reduce their cloud bills and become more cloud-agnostic. ![CAST AI KEDA Policies](/img/blog/cast-ai-ref-case/cast-ai-keda-2.png) In the system depicted above, we simulated a real-world scenario of producer-consumer-based work processing. The queue length triggers our built-in KEDA component to create pods used to process jobs stored in the queue. These pods are all scheduled on spot instances. When jobs are done, empty nodes are deleted. CAST AI handles potential spot instance interruptions gracefully. If an interruption occurs and a job is in-flight, the job is marked as failed and reschedules on another node. ## Looking towards the future with KEDA KEDA is an extremely powerful tool for scaling workloads horizontally. It allows workloads to scale to zero, taking up no resources when a job/process is not required. KEDA handles higher-order metrics with ease, enabling the next generation of auto-scaling solutions at CAST AI. So, where are we going with KEDA next? One of the challenges to solve automatically is choosing scaling parameters. Settings such as minReplicaCount and maxReplicaCount, along with the trigger threshold, have to be set manually today. For the most part, these are educated estimates and trial-and-error experiments performed by the engineering team. CAST AI is working on making these settings more automated based on application performance and the reaction to change in settings. We believe that is the next great KEDA challenge, so stay tuned for more! ## Glossary: *Add-on* An add-on is an application that helps another application perform more tasks or do it better. Apart from KEDA, CAST AI offers access to add-ons like Grafana, Grafana Loki, Evictor, Ingress Nginx, Cert Manager, Kubernetes Dashboard. *Policy* CAST AI users can turn on and manage policies that automate the process of scaling clusters up and down to optimize and reduce costs. ================================================ FILE: content/blog/2022-02-09-predictkube-scaler.md ================================================ +++ title = "Introducing PredictKube - an AI-based predictive autoscaler for KEDA made by Dysnix" date = 2022-02-14 author = "Daniel Yavorovych (Dysnix), Yuriy Khoma (Dysnix), Zbynek Roubalik (KEDA), Tom Kerkhove (KEDA)" aliases = [ "/blog/introducing-predictkube-for-keda-by-dysnix" ] +++ ## Introducing PredictKube—an AI-based predictive autoscaler for KEDA made by Dysnix [Dysnix](https://dysnix.com/) has been working with high-traffic backend systems for a long time, and the efficient scaling demand is what their team comes across each day. The engineers have understood that manually dealing with traffic fluctuations and preparations of infrastructure is inefficient because you need to deploy more resources _before_ the traffic increases, not at the moment the event happens. This strategy is problematic for two reasons: first, because it's often too late to scale when traffic has already arrived and second, resources will be overprovisioned and idle during the times that traffic isn't present. And when it comes to deciding how to wrap up this solution, Dysnix decided to rely on KEDA as it is the most universal and applicable component for application autoscaling in Kubernetes. KEDA is being used as a component on the client side of PredictKube that is responsible for transferring requests and scaling replicas. ## Dysnix's PredictKube integrates with KEDA Dysnix has built [PredictKube](https://predictkube.com/), a solution that can be used as a KEDA scaler that is responsible for resource balancing, and an AI model that has learned to react proactively to patterns of traffic activity, to help with both in-time scaling and solving the problem of overprovision. ![Overprovision](/img/blog/predictkube-scaler/overprovision.png "Overprovision") The predictive autoscaling process is possible thanks to an AI model that observes the requests-per-second (RPS) or CPU values for a period of time during a project and then shows the trend for up to 6 hours. PredictKube used customer and open data sources (we used data sets like [HTTP NASA logs](ftp://ita.ee.lbl.gov/html/contrib/NASA-HTTP.html)) to train the model and be specific about the cloud data and traffic trends. With this tool, Dysnix wants to decrease costs on the projects, analyze the data about traffic more efficiently, use cloud resources more responsibly, and build infrastructures that are "greener" and more performative (with fewer downtimes and delays) than others. ## How does PredictKube work? PredictKube works in two parts: 1. **On the KEDA side** The interface connects via API to the data sources about your traffic. PredictKube uses [Prometheus](https://prometheus.io/)—the industry standard for storing metrics. There, it anonymizes the data about the traffic on the client's side before sending it to the API, where the model then works with information that is completely impersonal. 2. **On the AI model side** Next, it is linked with a prediction mechanism—the AI model starts to get data about things that happen in your cloud project. Unlike standard rules-based algorithms such as Horizontal Pod Autoscaling (HPA), PredictKube uses Machine Learning models for time series data predicting, like CPU or RPS metrics. The more data you can provide to it from the start, the more precise the prediction will be. The 2+ weeks data will be enough for the beginning. ![PredictKube Scaler Diagram](/img/blog/predictkube-scaler/diagram.png) The rest is up to you! You can visualize the trend of prediction in, for example, [Grafana](https://grafana.com/). ## Launch of PredictKube 1. [Install KEDA](https://keda.sh/docs/latest/deploy/) 2. Get PredictKube API Key - Go to the [PredictKube website](https://predictkube.com/) - Register to get the API key in your email 3. Create PredictKube Credentials secret[​](https://docs.predictkube.com/quickstart-with-keda#create-predictkube-credentials-secret) ```bash API_KEY="" $ kubectl create secret generic predictkube-secrets --from-literal=apiKey=${API_KEY} ``` 4. Configure Predict Autoscaling[​](https://docs.predictkube.com/quickstart-with-keda#configure-predict-autoscaling) ```yml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret spec: secretTargetRef: - parameter: apiKey name: predictkube-secrets key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: example spec: scaleTargetRef: name: example-app pollingInterval: 60 cooldownPeriod: 300 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" # We recommend using a minimum of a 7-14 day time window as historical data prometheusAddress: http://kube-prometheus-stack-prometheus.monitoring:9090 query: sum(irate(http_requests_total{pod=~"example-app-.*"}[2m])) queryStep: "2m" # Note: query step duration for range prometheus queries threshold: '2000' # Value to start scaling for authenticationRef: name: keda-trigger-auth-predictkube-secret ``` 5. Check the status and get stats[​](https://docs.predictkube.com/quickstart-with-keda#get-stats) To check the configuration and status of the scaling created in the previous step, use the following command: ```bash $ kubectl get scaledobject example ``` To get stats to use for the scaling, use the following command: ```bash $ kubectl get hpa example ``` Now you can look at how scaling works at a graph in your visualization tool. This is an example of a graph Dysnix gets in one of their projects after using PredictKube: ![Grafana dashboard](/img/blog/predictkube-scaler/grafana.png "Grafana dashboard") On this graph, you'll see the graphs of stats for the environment with 2 hours cooldown period. The green trend shows predicted replicas number, a yellow one—ready replicas at a certain moment, and the ideal—the blue trend—showing the closest replicas number covering the RPS trend. If you need a template of such a dashboard to make your own, feel free to contact [Daniel](https://github.com/daniel-yavorovich) to get one. After everything is connected and deployed, you'll be able to change the time frame you're observing or just monitor the data as it comes. ## What's next? With this release, Dysnix has created the first milestone of predictive autoscaling for Kubernetes workloads. The team hopes you'll find it interesting and help to test it and improve it. If you have any questions to ask about the core functionality of PredictKube, you may contact the developers' team [here](https://predictkube.com/contact). And for all KEDA-related issues, share your feedback [via GitHub](https://github.com/kedacore/keda/discussions/2605). In the future, PredictKube plans to add more integrations with other data sources to autoscale based on other configurations of the projects. Also, there is an idea for implementing an event-based predictive scaling to make it possible to react on not only a trend but event appearance. You can contact the Dysnix team with any questions concerning the mechanics of PredictKube or learn more about the data usage in its [privacy policy](https://predictkube.com/privacy-policy). The following people will be happy to help: - [Daniel Yavorovych](https://github.com/daniel-yavorovich) — KEDA integration and Kubernetes-related questions; - [Yurij Khoma](https://www.linkedin.com/in/yuriy-khoma-5657a461/) — can comment more about the AI model that was created. Thanks for reading, Daniel Yavorovych and Yuriy Khoma on behalf of the PredictKube developers team. ================================================ FILE: content/blog/2022-03-10-how-zapier-uses-keda.md ================================================ +++ title = "How Zapier uses KEDA" date = 2022-03-10 author = "Ratnadeep Debnath (Zapier)" aliases = [ "/blog/how-zapier-uses-keda" ] +++ [RabbitMQ](https://www.rabbitmq.com/) is at the heart of Zap processing at [Zapier](https://zapier.com). We enqueue messages to RabbitMQ for each step in a Zap. These messages get consumed by our backend workers, which run on [Kubernetes](https://kubernetes.io). To keep up with the varying task loads in Zapier we need to scale our workers with our message backlog. For a long time, we scaled with CPU-based autoscaling using Kubernetes native Horizontal Pod Autoscale (HPA), where more tasks led to more processing, increasing CPU usage, and triggering our workers' autoscaling. It seemed to work pretty well, except for certain edge cases. We do a lot of [blocking I/O](https://medium.com/coderscorner/tale-of-client-server-and-socket-a6ef54a74763) in Python (we don’t use an event-based loop in our workers written in Python). This means that we could have a fleet of workers idling on blocking I/O with low CPU profiles while the queue keeps growing unbounded, as low CPU usage would prevent autoscaling from kicking in. In a situation where workers are idle while waiting for I/O, we could have a growing backlog of messages that a CPU-based autoscaler would miss. This situation allowed a traffic jam to form and introduce delays in processing Zap tasks. Ideally, we would like to scale our workers on both CPU and our backlog of ready messages in RabbitMQ. Unfortunately, Kubernetes’ native HPA does not support scaling based on RabbitMQ queue length out of the box. There is a potential solution by collecting RabbitMQ metrics in Prometheus, creating a custom metrics server, and configuring HPA to use these metrics. However, this is a lot of work and why reinvent the wheel when there’s KEDA. We have installed KEDA in our Kubernetes clusters and started opting into KEDA for autoscaling. Our goal is to autoscale our workers not just based on CPU usage, but also based on the number of ready messages in RabbitMQ queues they are consuming from. At Zapier, we use KEDA to autoscale our workers not just based on CPU usage, but also based on the number of ready messages in RabbitMQ queues they are consuming from. We monitor our KEDA setup in Grafana using Prometheus metrics, and use Prometheus rules to alert on errors. Using KEDA to autoscale our workers significantly prevented delays in our Zap processing due to blocked I/O calls. We are slowly updating apps at Zapier to use KEDA. **Read the rest of this [post on how Zapier uses KEDA](https://www.cncf.io/blog/2022/01/21/keda-at-zapier/) on the Cloud Native Computing Foundation blog.** ================================================ FILE: content/blog/2022-08-10-keda-2.8.0-release.md ================================================ +++ title = "Announcing KEDA v2.8 🎉" date = 2022-08-10 author = "Jeff Hollan (KEDA), Tom Kerkhove (KEDA)" aliases = [ "/blog/2.8.0-release" ] +++ We recently completed our most recent release: 2.8.0 🎉! Here are some highlights: - Introduction of new AWS DynomoDB Streams & NATS JetStream scalers. - Introduction of new Azure AD Workload Identity authentication provider. - Support for specifying `minReplicaCount` in ScaledJob. - Support to customize the HPA name. - Support for permission segregation when using Azure AD Pod / Workload Identity - Additional features to various scalers such as AWS SQS, Azure Pipelines, CPU, GCP Stackdriver, Kafka, Memory, Prometheus Here are the new deprecation(s) as of this release: - `rolloutStrategy` in ScaledJob is deprecated in favor of `rollout.strategy` Let's have a closer look. ## New & Improved Scalers KEDA now has 50+ built-in scalers, giving you instant access to provide event driven scale across a variety of sources. New with this release are: - AWS DynamoDB Streams ([docs](https://keda.sh/docs/2.8/scalers/aws-dynamodb-streams/)) - NATS JetStream ([docs](https://keda.sh/docs/2.8/scalers/nats-jetstream/)) In addition to new scalers, various new features and improvements were added to AWS SQS, Azure Pipelines, CPU, GCP Stackdriver, Kafka, Memory, and Prometheus scalers. ## Activation and Scaling Thresholds Previously in KEDA, when scaling from 0 to 1, KEDA would "activate" (scale to 1) a resource when *any* activity happened on that event source. For example, if using a queue, a single message on the queue would trigger activation and scale. As of this release, we now allow you to set an `activationThreshold` for many scalers which is the metric that must be hit before scaling to 1. This would allow you to delay scaling up to 1 until *n* number of messages were unprocessed. This pairs with other thresholds and target values for scaling from 1 to *n* instances, where the HPA will scale out to *n* instances based on the current event metric and the defined threshold values. Details on thresholds and the new activation thresholds can be found [in the KEDA concept docs](https://keda.sh/docs/2.8/concepts/scaling-deployments/#activating-and-scaling-thresholds) ## Introducing support for Azure AD Workload Identity & identity segregation One critical piece of functionality in KEDA is the ability to authenticate with different event sources. The `TriggerAuthentication` CRD allows you to define secure secrets and identities to use within your scaled objects and jobs. As of v2.8.0, you can now use [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) which is supported by using `azure-workload` as a valid pod identity provider. We want to strive to be as secure as we can and reduce the risk of breach by allowing end-users to use least-privilege principle. This is crucial because KEDA is installed once and available to the whole Kubernetes cluster. However, identities used for Azure AD Pod Identity and Azure AD Workload Identity providers are applied on KEDA itself which means it can be used by all applications. That is why we are **introducing segregation of permissions within KEDA and its used identity/identities**. This means you don't have to grant the KEDA pod too many permissions to too many sources, and can now specify an `identityId` in your `TriggerAuthentication` allowing to define the identity to use which has more scoped permissions for specific triggers. More details can be found in the KEDA [Authentication documentation](https://keda.sh/docs/2.8/concepts/authentication/). ## `rolloutStrategy` in ScaledJob is deprecated in favor of `rollout.strategy` As of this release, `rolloutStrategy` in ScaledJob is deprecated in favor of `rollout.strategy` and ask all end-users to migrate to `rollout.strategy` instead. This change has been introduced so that end-users have more control over how rollouts are performed and have introduced new capabilities such as `rollout.propagationPolicy` to compliment this. End-users who are still using `rolloutStrategy` will not be impacted, until it will be removed in KEDA 3.x. Learn more in our [new documentation](https://keda.sh/docs/2.8/concepts/scaling-jobs/) and join our [GitHub Discussion](https://github.com/kedacore/keda/discussions/3552) if you have questions/problems migrating. ## Simplified end-to-end testing experience for contributors We've added some new features to our end to end testing and PR process. The test framework used to coordinate end to end tests was moved from TypeScript to Go, so contributors can stick within a single language for the codebase. We also improved the Pull Request process so that all PRs will be blocked until e2e tests pass or until a label `ok-to-merge` is added, and created a new team `keda-e2e-test-executors` who can now trigger end to end tests to run. ## And more... This is just some of the highlights for the latest release. You can find the full release notes can be [found here](https://github.com/kedacore/keda/releases/tag/v2.8.0). The next KEDA release is scheduled for the first week of November 2022. Thanks to everyone for helping make KEDA better! ================================================ FILE: content/blog/2022-09-27-http-add-on-is-on-hold.md ================================================ +++ title = "HTTP add-on is looking for contributors by end of November" date = 2022-09-27 author = "Tom Kerkhove (KEDA)" aliases = [] +++ On Nov 25, 2020, we started the HTTP add-on based on [@arschles](https://github.com/arschles) his initial POC which closed a big gap in KEDA's story - HTTP autoscaling without a dependency on an external system, such as Prometheus. To this day, the autoscaling community has a very high demand for a solution in this area that auto scales and works in the same manner as the KEDA core. With the add-on, we want to cover all traffic patterns ranging from ingress, to service meshes and service-to-service communication and make it super simple to autoscale (and with scale-to-zero support). As time passed by, we've seen [@arschles](https://github.com/arschles) lead the HTTP add-on to a beta stage and have defined the [requirements for it to become a GA add-on](https://github.com/orgs/kedacore/projects/6/views/9). Unfortunately we have seen very few contributions to the project and [@arschles](https://github.com/arschles) has switched roles and is unable to maintain it anymore. 📢 **Because of that, we are doing an active call for contributors and will assess the future of the HTTP add-on by the end of November based on the community and (hopefully) contribution growth. Until then, the project is on-hold.** 📢 **If we do not have at least 3 contributors take charge we will have to see what alternatives we have.** We'd also want to take the time to say a big thank you to [@arschles](https://github.com/arschles) for his hard work on this and hopefully we can continue taking it forward! Join our discussion on [GitHub](https://github.com/kedacore/http-add-on/discussions/523) if you want to stay up-to-date or want to get involved. ================================================ FILE: content/blog/2022-12-12-keda-2.9.0-release.md ================================================ +++ title = "Announcing KEDA v2.9 🎉" date = 2022-12-12 author = "Jeff Hollan (Snowflake), Tom Kerkhove (Microsoft) and Zbynek Roubalik (Red Hat)" aliases = [ "/blog/releases/2.9.0" ] +++ We recently completed our most recent release: 2.9.0 🎉! Here are some highlights: - Newly published Deprecations and Breaking Change policy ([docs](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md)) - Introduce new CouchDB, Etcd & Loki scalers - Introduce off-the-shelf Grafana dashboard for application autoscaling - Introduce improved operational metrics in Prometheus - Introduce capability to cache metric values for a scaler during the polling interval (experimental feature) - Performance improvements and architecture changes on how metrics are exposed to Kubernetes - Azure Key Vault authentication provider now supports pod identities for authentication - A ton of new features and fixes for some of our 50+ scalers Potential breaking changes and deprecations include: - As per our [support policy](https://github.com/kedacore/governance/blob/main/SUPPORT.md), Kubernetes v1.23 or above is required and support for Kubernetes v1.22 or below was removed ([docs](https://keda.sh/docs/2.9/operate/cluster/#kubernetes-compatibility)) - Upgrading the API version of managed HPA objects from `autoscaling/v2beta2` to `autoscaling/v2` - Prometheus metrics on KEDA Metric Server are deprecated in favor of Prometheus metrics on KEDA Operator ([#3972](https://github.com/kedacore/keda/issues/3972) | [Discussion](https://github.com/kedacore/keda/discussions/3973)) You can keep an eye and join the discussion for future breaking changes and deprecations [in our GitHub issues](https://github.com/kedacore/keda/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Abreaking-change). ## New & Improved Scalers KEDA now has 50+ built-in scalers, giving you instant access to provide event driven scale across a variety of sources. New scalers in this release are: - Etcd ([docs](https://keda.sh/docs/scalers/etcd/)) - CouchDB ([docs](https://keda.sh/docs/scalers/couchdb/)) - Loki ([docs](https://keda.sh/docs/scalers/loki/)) In addition to new scalers, various new features and improvements were added to Kafka, Azure Event Hubs, Azure Pipelines, GCP Storage, Metrics, NATS Jetstream, Prometheus, Pulsar, Azure Blob, GCP Stackdriver, and New Relic scalers. Here are a few improvement highlights: - **AWS Scalers:** Introduce new AWS endpoint URL settings - **Apache Kafka Scaler:** Support for SASL/OAuth bearer authentication and/orlimiting Kafka partitions KEDA will monitor - **Azure Event Hubs Scaler:** Support Azure Active Directory Pod & Workload Identity authentication for Storage Blobs, Dapr checkpointing and using connection strings for Event Hub namespace instead of the Event Hub itself. - **Azure Service Bus Scaler:** Support for Shared Access Signature (SAS) tokens for authentication and use of regex in `queueName` / `subscriptionName` - **ElasticSearch Scaler:** Support for Elastic Cloud - **GCP Storage Scaler:** Support for blob prefix & delimiters - **Metrics API Scaler:** Support for unsafeSsl parameter to skip certificate validation when connecting over HTTPS - **NATS Jetstream Scaler:** Support for clustered scenarios - **NATS Scalers:** Support HTTPS protocol - **Prometheus Scaler:** Introduce skipping of certificate check for unsigned certs - **Pulsar Scaler:** Add support for basic and bearer token authentication along with support for partitioned topics Details on the underlying fixes can be found in the [changelog](https://github.com/kedacore/keda/blob/main/CHANGELOG.md#v290). ## Production-grade operating experience for autoscaling applications There are a number of improvements into the ways KEDA provides operational information in Prometheus and how you can consume it. For starters, **our operator now exposes Prometheus metrics** which can be scraped on port `8080` at `/metrics`. It provides the same set of metrics as the metric server (although renamed) offers today, in addition to a few new metrics and the introduction of a `ScalerName` label. The metrics are moving given we are changing how KEDA is integrating with external systems so that we can improve the performance and reduce the load on those external systems. As part of this, **we are deprecating the KEDA-specific metrics in our metric server** and recommend end-users to use the metrics in the operator. Join our [conversation there](https://github.com/kedacore/keda/discussions/3973). Next, we have **introduced `keda_resource_totals` and `keda_trigger_totals` as metrics** that provide insights into your autoscaling landscape and the various autoscaling triggers that are being used. Metrics are great - But they have to be consumed. That's why we **introduced a new Grafana dashboard allows end-users to easily visualize the KEDA metrics in Grafana** to see how your applications are scaling: ![Grafana Dashboard](/img/blog/v2.9-release/grafana-dashboard.png) Lastly, **end-users using `ScaledJobs` can now see what the minimum replica count is when inspecting resources** through the Kubernetes API. Learn more about our available Prometheus metrics and our Grafana dashboard in our [docs](https://keda.sh/docs/operate/prometheus/). ## Change in the architecture and metrics caching In this release we focused on performance improvements. Let's talk about these changes: KEDA has two main components - the Operator and the Metrics Server. The Operator monitors ScaledObjects and ScaledJobs resources, and checks activity on the external service. The Metrics Server handles requests and queries about metric values used for scaling from Kubernetes' Horizontal Pod Autoscaler (HPA) by checking the external service. In previous versions of KEDA, each component needed to handle its own connection to the external service. In version 2.9, we have changed this and moved the connection logic to the Operator component. We are now using gRPC for the connection between the Metrics Server and Operator. This has several benefits, including reduced load on the external service, as there is only one connection from the Operator. We have also introduced an experimental feature called metrics value caching. This caches the values in the Operator and can be reused in future. It can even further reduce the load on the external service. By default, Kubernetes' HPA asks for a metric value every few seconds (as defined b `--horizontal-pod-autoscaler-sync-period` flag set by Kuberentes admins, which is usually set to 15 seconds). This can create unnecessary load on the external service. Caching metric values per trigger in a ScaledObject can help to overcome this problem. This is an optional feature, and can be enabled by setting the `useCachedMetrics` flag, then metric values are cached during polling interval as defined by `pollingInterval` flag and request comming from HPA to KEDA Metrics Server are served from this cache. We are excited about the potential uses for this feature in the future, including using AI and machine learning models to affect metric values. Stay tuned for more updates and improvements in future releases of KEDA. ## New ways to authenticate In this release we have added some additional configuration options for triggers: Azure Key Vault authentication provider now allows end-users to use pod identities for authentication for improved simplicity & security: ```diff azureKeyVault: # Optional. vaultUri: https://keda.vault.azure.net + podIdentity: + provider: azure-workload # Optionally, you can specify a user-assigned identity: identityId: secrets: # Required. - parameter: connection name: ServiceBus-ConnectionString ``` Our Azure AD Pod Identity authentication now also has improved logs around integration with `aad-pod-identity` for simplified troubleshooting. ## And more... This is just some of the highlights for the latest release. You can find the full release notes [here](https://github.com/kedacore/keda/releases/tag/v2.9.0). The next KEDA release is [scheduled for March 2023](https://github.com/kedacore/keda/blob/main/ROADMAP.md). Thanks to everyone for helping make KEDA better! ================================================ FILE: content/blog/2023-05-02-certificate-improvements.md ================================================ +++ title = "Securing autoscaling with the newly improved certificate management in KEDA 2.10" date = 2023-05-16 author = "Jorge Turrado (SCRM Lidl International Hub)" aliases = [ "/blog/exploring-new-certificate-management" ] +++ Recently, we have release KEDA v2.10 that introduced a key improvement for managing certificates and your autoscaling security: - Encryption of any communication between KEDA components. - Support for providing your own certificates for internal communications. - Support for using customs certificate authorities (CA). With these new improvements, we can dramatically improve the security between KEDA components, the Kubernetes API server and scaler sources. Let's take a closer look. ## Where do we come from? KEDA is a component that runs on kubernetes, receiving request from kubernetes API server (from the HPA Controller) but also integrates with multiple external sources (upstreams). To improve our integration with Kubernetes' API server, we decided to skip the certificate validation using a built-in property, `insecureSkipTLSVerify`. Thanks to it, we could use self generate the metrics server certificate on every restart, not having to manage it and simplifying the process, but using at least an encrypted channel between kubernetes and KEDA metrics server. The second case was more complicated... We really trust in the encryption as the way to achieve secure connections, so we wanted to support encrypted connection wherever a user wants to use them, but using self-signed certificates is a really common scenario and that was complex to manage. As a first and fast option, we decided to support an extra parameter in some scalers to skip the certificate validation, allowing these scenarios. Before version 2.9, KEDA was composed by 2 different components with totally different goals, the operator and the metrics server. As both components were independent by design, so we didn't need to secure anything between them, but it changed in version v2.9. [As we announced in KEDA v2.9 release](/blog/releases/2.9.0), we introduced an important change in the architecture. Now we have 2 components, but they are strong related and they need to have a secured channel for the internal communications. At that point, we decided to release v2.9 with this gap in terms of encryption for internal communications, but having the commitment of solving this for the next version. ## Securing connections between KEDA components and Kubernetes API server As part of version 2.10, we have released a mechanism to generate a self-signed certificate that will be used to encrypt all the traffic between various KEDA components but also patching `apiservice` and the new validating webhook to include the `caBundle`. Thanks to this mechanism, we can encrypt all the traffic between KEDA components with mutual TLS (TLSv1.3). Additionally, it allows us to remove the `insecureSkipTLSVerify` flag for the Kubernetes API Server making all our communications more secure between Kubernetes and KEDA. By default, KEDA uses self-signed certificates for various things and the operator is in charge of generating and rotating them. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that is mounted to all KEDA components to `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). The KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, end-user specific certificates can be stored in the `kedaorg-certs` secret and will automatically update all components (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. ## Register your own CA in KEDA Operator Trusted Store With our recent architecture changes in v2.9, our operator is the only component that needs to interact with the (scaler) dependencies. This has been the last requirement for solving the problem of registering CAs to avoid the usage of `unsafeSsl` because even though it works, it also allows any certificate, which is not totally secure. To overcome this problem, KEDA supports registering custom CAs that will be used by various SDKs where possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. ## A practical example using helm With KEDA, we strive to make application autoscaling simple and that is why we have integrated cert-manager manifests as an optional component of our Helm chart. By doing so, you can use cert-manager to generate, rotate and patch services as part of the Helm installation (cert manager needs to be installed up front). ```yaml certificates: autoGenerated: false # disables the cert-generation by the operator certManager: enabled: true # enables the certificate generation using cert manager generateCA: true # uses a self-signed generated CA # caSecretName: "kedaorg-ca" ``` To provide a CA to be used for generating certificates, you can store it as a secret (in the same namespace where KEDA is installed) and configure the secret. This will register an issuer based on it for generating the certificates. ```yaml certificates: autoGenerated: false # disables the cert-generation by the operator certManager: enabled: true # enables the certificate generation using cert manager generateCA: false # uses a self-signed generated CA caSecretName: "kedaorg-ca" # secret name where the CA is stored ``` > Note: As KEDA requires the services to be correctly patched, when the cert manager integration is enabled, the manifests are annotated. If you provide a CA via secret, the secret has to be annotated with `cert-manager.io/allow-direct-injection: "true"`. Otherwise, the cert manager cannot patch the resources with the CA. ## Conclusion The improvements made to certificate management in KEDA 2.10 are a significant step forward in enhancing security and reliability, but they are not the only ones. We are working to make KEDA even more secure by default with small actions like limiting the default minimum TLS version or correctly using security contexts in Kubernetes. If you want to dive deeper, don't hesitate to check the [repo changelog](https://github.com/kedacore/keda/blob/main/CHANGELOG.md), where every change is listed. And stay tuned to future posts about other security tips! ;) ================================================ FILE: content/blog/2023-05-04-keda-survey.md ================================================ +++ title = "Help shape the future of KEDA with our survey 📝" date = 2023-05-04 author = "KEDA Maintainers" aliases = [ "/blog/keda-survey" ] +++ As maintainers, we are always eager to learn who is using KEDA ([become a listed end-user!](https://github.com/kedacore/keda#adopters---become-a-listed-keda-user)) and how they are using KEDA to scale their cloud-native workloads. Our job is to make sure that your are able to scale the workloads that you run with as less friction as possible, production-grade security, insights on what is going on, etc. In order to be successful, we need to learn how big of KEDA deployments end-users are running, what is causing frustration and what we can improve. This is why we have created a survey to gain more insights and make KEDA better. **If you want to help shape KEDA's future, feel free to fill in [our 2-minute survey](https://forms.gle/nC393JzCqK1evjcH9).** Proud of your autoscaling infrastructure? You're more then welcome to show it in our [KEDA deployment show & tell discussion](https://github.com/kedacore/keda/discussions/4410) as well! Thank you for helping make KEDA better! ================================================ FILE: content/blog/2023-08-22-keda-cncf-graduation.md ================================================ +++ title = "KEDA is graduating to CNCF Graduated project 🎉" date = 2023-08-22 author = "KEDA Maintainers" aliases = [ "/blog/keda-cncf-graduation" ] +++ In 2019, KEDA embarked on a mission to make application autoscaling on Kubernetes dead-simple. Our aim was to make sure that every Kubernetes platform can use it to scale applications without having to worry about the underlying autoscaling infrastructure. As part of that mission, we wanted to build a vendor-neutral project that is open to everyone and nicely integrates with other tools. Because of that, the KEDA maintainers decided that the Cloud Native Computing Foundation (CNCF) was a natural fit and got accepted as a sandbox project in 2020. KEDA started evolving and became a more mature autoscaler which came with more scalers out-of-the-box and introduced new concepts such as scaled jobs, trigger authentication, operational metrics, and more. The community started growing as well, the project governance matured and KEDA became a CNCF Incubation project in 2021. In the past year and a half, KEDA started focussing on making it easier to use for larger enterprises and use KEDA at-scale serving thousands of scaled objects with low performance impact. Today is another important milestone in KEDA's journey - **We are excited to announce that the [CNCF has accepted to move KEDA to a CNCF Graduated project](https://www.cncf.io/announcements/2023/08/22/cloud-native-computing-foundation-announces-graduation-of-kubernetes-autoscaler-keda/) next to projects such as Kubernetes, Prometheus, Istio and others! 🎉.** It has been great to see how KEDA has been adopted and is being used by more than 45+ listed end-users: ![architecture diagram](/img/blog/keda-cncf-graduation/keda-graduation-end-users.gif) We would like to thank everyone who has contributed to KEDA, installed KEDA, gave feedback or talked about it in the community. Additionally, we want to thank our CNCF TOC sponsors (Cathy Zhang & Ricardo Rocha) for their support, help and trust in our project as part of the graduation process! We are excited about this new phase of KEDA and are looking forward to making KEDA even better! Happy scaling, KEDA maintainers. ================================================ FILE: content/blog/2025-09-15-gcp-deprecations.md ================================================ +++ title = "Google Cloud deprecations" date = 2025-09-15 author = "Jorge Turrado (SCRM Lidl International Hub)" aliases = [ "/blog/gcp-deprecations" ] +++ One year ago, Google Cloud deprecated its [Monitoring Query Language](https://cloud.google.com/monitoring/mql) in favor of a PromQL-based API: > Announcement: Starting on October 22, 2024, Monitoring Query Language (MQL) will no longer be a recommended query language for Cloud Monitoring. Certain usability features will be disabled, but you can still run MQL queries in Metrics Explorer, and dashboards and alerting policies that use MQL will continue to work. For more information, see the [deprecation notice for MQL](https://cloud.google.com/stackdriver/docs/deprecations/mql). Although the deprecation announcement also says that "***MQL is not being shut down**. You will still be able to create and run MQL queries, and dashboards and alerting policies that use MQL queries will continue to work.*" we have decided to deprecate our current GCP scalers which rely on MQL ("[Cloud Tasks](https://keda.sh/docs/latest/scalers/gcp-cloud-tasks/)", "[Pub/Sub](https://keda.sh/docs/latest/scalers/gcp-pub-sub/)" and "[Stackdriver](https://keda.sh/docs/latest/scalers/gcp-stackdriver/)") keeping those that don't rely on MQL but use other SDKs, untouched (currently only "[Storage](https://keda.sh/docs/latest/scalers/gcp-storage/)" remains supported). Does this mean KEDA no longer supports Google Cloud Platform? Absolutely not! We are committed to making the autoscaling dead simple on any vendor! In this case, we suggest moving the current deprecated scalers to [Prometheus scaler](https://keda.sh/docs/latest/scalers/prometheus/) for GCP. > **Note**: GCP exposes the metrics via Prometheus endpoints without any extra configuration or services; you don't need to deploy anything else to get these metrics via Prometheus. **We don't plan to remove these affected scalers as long as GCP supports MQL** but we strongly encourage migrating to a Prometheus-like approach to avoid service disruptions in case of any change on GCP. ## How to migrate The migration path differs slightly depending on the scaler, but these are some examples: ### Migrate Google Cloud Platform Cloud Tasks From the current trigger spec: - `projectID` is not included as part of `serverAddress` value (`https://monitoring.googleapis.com/v1/projects/{{projectID}}/location/global/prometheus`). - `value` and `activationValue` are replaced by `threshold` and `activationThreshold`. - `queueName` is now included as part of `query` value (`{"__name__"="cloudtasks.googleapis.com/queue/depth","monitored_resource"="cloud_tasks_queue","queue_id"="{{queueName}}"}`). - `GoogleApplicationCredentials`, `credentialsFromEnv`, `credentialsFromEnvFile` don't change. For example, these scalers are equivalent: ```yaml - type: gcp-cloudtasks metadata: projectID: "my-keda-project" queueName: "consumer-queue" value: "5" activationValue: "0" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` ```yaml - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-keda-project/location/global/prometheus query: '{"__name__"="cloudtasks.googleapis.com/queue/depth","monitored_resource"="cloud_tasks_queue","queue_id"="consumer-queue"}' threshold: "5" activationThreshold: "0" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` ### Migrate Google Cloud Platform Stackdriver From the current trigger spec: - `projectID` is not included as part of `serverAddress` value (`https://monitoring.googleapis.com/v1/projects/{{projectID}}/location/global/prometheus`). - `targetValue ` and `activationTargetValue` are replaced by `threshold` and `activationThreshold`. - `filter` is replaced by `query`. - `alignmentPeriodSeconds` is now included as part of `query` value. - `alignmentAligner` is now included as part of `query` value. - `GoogleApplicationCredentials`, `credentialsFromEnv`, `credentialsFromEnvFile` don't change. For example, these scalers are equivalent: ```yaml - type: gcp-stackdriver metadata: projectId: "my-keda-project" filter: 'metric.type="pubsub.googleapis.com/topic/num_unacked_messages_by_region" AND resource.type="pubsub_topic" AND resource.label.topic_id="my-keda-topic"' targetValue: "5" activationTargetValue: "0" alignmentPeriodSeconds: "60" alignmentAligner: max credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` ```yaml - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-keda-project/location/global/prometheus query: 'max(max_over_time({"__name__"="pubsub.googleapis.com/topic/num_unacked_messages_by_region","monitored_resource"="pubsub_topic","topic_id"="my-keda-topic"}[1m]))' threshold: "5" activationThreshold: "0" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` ### Migrate Google Cloud Platform Pub/Sub From the current trigger spec: - `value ` and `activationValue` are replaced by `threshold` and `activationThreshold`. - `topicName` and `subscriptionName` are now included as part of `query` value. - `aggregation` is now included as part of `query` value. - `mode` is now included as part of `query` value. - `GoogleApplicationCredentials`, `credentialsFromEnv`, `credentialsFromEnvFile` don't change. For example, these scalers are equivalent: ```yaml - type: gcp-pubsub metadata: topicName: my-topic mode: MessageSizes aggregation: count value: "5" activationValue: "0" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` ```yaml - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-keda-project/location/global/prometheus query: 'increase({"__name__"="pubsub.googleapis.com:topic_message_sizes_count","monitored_resource"="pubsub_topic","topic_id"="my-topic"}[2m])' threshold: "5" activationThreshold: "0" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` KEDA maintainers. ================================================ FILE: content/blog/_index.md ================================================ +++ title = "The KEDA Blog" description = "Updates, tutorials, and more" +++ ================================================ FILE: content/community.md ================================================ +++ title = "Community" description = "How you can get involved with the KEDA ecosystem" +++ ## Get Involved {{< include "get-involved.md" >}} ## End-Users A variety of users are autoscaling applications with KEDA: {{< user-icons >}} ## Partners KEDA is community-supported and built by our community, including the following companies: {{< partners-icons >}} ## Supported by KEDA community is supported by the following companies that provide their services for free: {{< supportedby-icons >}} ================================================ FILE: content/docs/1.4/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/1.4/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates two custom resources: 1. `scaledobjects.keda.k8s.io` 1. `triggerauthentications.keda.k8s.io` These custom resources enable you to map an event source (and the authentication to that event source) to a deployment or job for scaling. The `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes deployment. A `ScaledObject` may also reference a `TriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/1.4/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use credentials or delegate authentication with `TriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/1.4/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: deploymentName: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `containerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.containerName of ScaledObject ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.containerName of ScaledObject ``` **Assumptions:** `containerName` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise. ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none ``` #### Azure Pod Identity Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which let's you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: false ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set aadPodIdentity={your-label-name}`. #### AWS EKS Pod Identity Webhook [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: false ``` #### AWS Kiam Pod Identity [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: false ``` ================================================ FILE: content/docs/1.4/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interface: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#4-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#5-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates replicaCount based on metric value and target value. ### External Scaler GRPC interface KEDA comes with an external scaler [`external`](../scalers/external.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. Few things to notice: - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: deploymentName: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/1.4/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments" weight = 200 +++ ## Overview Deployments are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your deployment out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a deployment. Each replica of a deployment is actively pulling items from the event source. With KEDA and scaling deployments you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## ScaledObject spec This specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: deploymentName: {deployment-name} # must be in the same namespace as the ScaledObject containerName: {container-name} #Optional. Default: deployment.spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 triggers: # {list of triggers to activate the deployment} ``` You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: deploymentName: {deployment-name} # must be in the same namespace containerName: {container-name} #Optional. Default: deployment.spec.template.spec.containers[0] ``` The name of the deployment this scaledObject is for. This is the deployment KEDA will scale up and setup an HPA for based on the triggers defined in `triggers:`. Make sure to include the deployment name in the label as well, otherwise the metrics provider will not be able to query the metrics for the scaled object and 1-n scale will be broken. **Assumptions:** `deploymentName` is in the same namespace as the scaledObject. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the deployment up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the deployment back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment`, KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml minReplicaCount: 0 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the deployment down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given deployment. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/1.4/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. ## ScaledObject spec This specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleType: job jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ================================================ FILE: content/docs/1.4/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/1.4/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 2** ```sh helm install keda kedacore/keda --version 1.4.2 --namespace keda --create-namespace ``` **Helm 3** ```sh kubectl create namespace keda helm install keda kedacore/keda --version 1.4.2 --namespace keda ``` ### Uninstall If you want to remove KEDA from a cluster you can run one of the following: **Using Helm 3** ```sh helm uninstall -n keda keda kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml ``` **Using Helm 2** ```sh helm delete --purge keda kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator 2. Create namespace `keda` 3. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:**Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. We provide sample YAML declarations which includes our CRD in the released zip and tar.gz package files which are available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Download the zip or tar.gz file, unpack it, enter the unpacked folder and just run the following commands. ```sh kubectl apply -f ./crds kubectl apply -f ./ ``` You can also find the same YAML declarations in our `/deploy` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda && git checkout tags/v1.4.1 kubectl apply -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl apply -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml kubectl apply -f deploy/ ``` ### Uninstall You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh kubectl delete -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl delete -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml kubectl delete -f deploy/ ``` ================================================ FILE: content/docs/1.4/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq >}} ================================================ FILE: content/docs/1.4/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/1.4/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: # brokerList: kafka.svc:9092 - deprecated bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' ``` **Parameter list:** - `brokerList` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap (DEPRECATED). - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Topic on which processing the offset lag. - `lagThreshold` - How much the stream is lagging on the current consumer group. Default is 10. Optional. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing authMode, username, password. If your kafka cluster does not have sasl authentication turned on, you will not need to pay attention to it. **Credential based authentication:** - `authMode` - Kafka sasl auth mode. (Values: `none`, `sasl_plaintext`, `sasl_ssl`, `sasl_ssl_plain`, `sasl_scram_sha256`, `sasl_scram_sha512`. Default: `none`, Optional) - `username` - (Optional) - `password` - (Optional) - `ca` - Certificate authority file for TLS client authentication `sasl_ssl`. (Optional) - `cert` - Certificate for client authentication `sasl_ssl`. (Optional) - `key` - Key for client authentication with `sasl_ssl`. Optional) ### Example Your kafka cluster no sasl auth: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" ``` Your kafka cluster turn on sasl auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: authMode: "sasl_plaintext" username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: authMode name: keda-kafka-secrets key: authMode - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/1.4/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyID: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKey: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/1.4/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/1.4/concepts/authentication/). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/1.4/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for `ApproximateNumberOfMessages` in the SQS Queue. (Default: `5`, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/1.4/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." notice = "As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connection: EVENTHUB_CONNECTIONSTRING_ENV_NAME # Connection string for Event Hub namespace appended with "EntityPath=" storageConnection: STORAGE_CONNECTIONSTRING_ENV_NAME # Connection string for account used to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. consumerGroup: $Default # Optional. Consumer group of event hub consumer. Default: $Default unprocessedEventThreshold: '64' # Optional. Target number of unprocessed events across all partitions in Event Hub for HPA. Default: 64 events. blobContainer: 'name_of_container' # Optional. Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function. ``` The `connection` value is the name of the environment variable your deployment uses to get the Event Hub connection string which is appended with the Event Hub name using Entity Path variable. `storageConnection` is the name of the environment variable your deployment uses to get the Storage connection string. Environment variables are usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required connection: EventHub storageConnection: AzureWebJobsStorage # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/1.4/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "1" activeDirectoryClientId: CLIENT_ID_ENV_NAME activeDirectoryClientPassword: CLIENT_PASSWORD_ENV_NAME ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource. The format is `"//"`. - `tenantId` - Tenant id for the Azure resource. Used for authentication. - `subscriptionId` - Subscription id for the Azure resource. Used for determining the full resource URI. - `resourceGroupName` - Resource group for the Azure resource. - `metricName` - Name of the Azure Monitor metric. Must be an officially supported metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Filter to define a more specific part of the resource. You can filter by supported dimensions of the metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Aggregation interval of the metric. Reported in the format `"mm:hh:ss"`. (Default: `"0:5:0"`, Optional) - `metricAggregationType` - Aggregation method of the Azure monitor metric. Some possible values include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). No default. - `targetValue` - Target value for the Azure metric to use in the HPA. - `activeDirectoryClientId` - Name of the environment variable that contains the active directory client id. Should have the RBAC role of `Monitoring Reader`. - `activeDirectoryClientPassword` - Name of the environment variable that contains the active directory client password. Should have the RBAC role of `Monitoring Reader`. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials. **Credential based authentication:** - `activeDirectoryClientId` - Active Directory client id. - `activeDirectoryClientPassword` - Active Directory client password. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler labels: app: azure-monitor-example spec: scaleTargetRef: deploymentName: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/1.4/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connection: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional queueLength: "5" # Optional. Subscription length target for HPA. Default: 5 messages ``` **Parameter list:** - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connection` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `queueLength` - Amount of active messages in your Azure Service Bus queue or topic to scale on. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional queueLength: "5" # default 5 authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/1.4/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by delete/move the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob # Required: Name of Azure Blob Storage container blobCount: '5' # Optional. Amount of blobs to scale out on. Default: 5 blobs connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Optional if TriggerAuthentication defined with pod identity or connection string authentication. blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "/" ``` The `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/1.4/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: functionsqueue queueLength: '5' # Optional. Queue length target for HPA. Default: 5 messages connection: STORAGE_CONNECTIONSTRING_ENV_NAME ``` The `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Required: connection OR authenticationRef that defines connection connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/1.4/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST # Required host:port format password: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required ``` > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: deploymentName: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/1.4/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentials` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: deploymentName: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ================================================ FILE: content/docs/1.4/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Dimension name of the metric. - `dimensionValue` - Dimension value of the metric. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Min value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric. Equivalent to the earliest start time of the end time. (Default: `300`, Optional) - `metricFilter` - Aggregation method of the metric. (Values: `max`, `min`, `average`, `sum`, `variance`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric. (Default: `300`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/1.4/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 # Address of the gRPC liiklus API endpoint group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # default 10, the target lag for HPA groupVersion: 1 # default 0, the groupVersion to consider when looking at messages. See https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java ``` ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: deploymentName: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/1.4/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionString` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `username` - Used to access MySQL database. - `password` - Used for the given user, this should be blank (no password) or point to an environment variable with the password. - `host` - Host of the database. - `port` - Port of the database. - `dbName` - As name of the database. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connection` - Connection string for MySQL database. **Password Authentication:** - `connection` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user@tcp(mysql:3306)/stats_db --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: deploymentName: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/1.4/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" # Location of the Nats Streaming monitoring endpoint queueGroup: "grp1" # Queue group name of the subscribers durableName: "ImDurable" # Must identify the durability name used by the subscribers subject: "Test" # Name of channel lagThreshold: "10" # Configures the TargetAverageValue on the Horizontal Pod Autoscaler (HPA)). ``` ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: deploymentName: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/1.4/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connection` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `password:` - Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string: ```yaml triggers: - type: postgresql metadata: connection: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" password: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: postgresql sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: deploymentName: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connection: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/1.4/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response ``` The `serverAddress` indicates where Prometheus is running which contains the configured metric defined in `metricName` or `query`. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: deploymentName: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` ================================================ FILE: content/docs/1.4/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: RabbitMqHost queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages queueName: testqueue includeUnacked: 'true' # Optional, use unacked + ready messages count apiHost: RabbitApiHost # Optional HTTP management API endpoint ``` The `host` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` `apiHost` has the similar format but for HTTP API endpoint, like `https://guest:password@localhost:443/vhostname`. Note it has optional vhost name after the host slash which will be used to scope API request. By default, `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages. If `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count. ### Authentication Parameters Not supported yet. ### Example AMQP protocol: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: deploymentName: rabbitmq-deployment triggers: - type: rabbitmq metadata: # Required host: RabbitMqHost # references a value of format amqp://guest:password@localhost:5672/vhost queueName: testqueue queueLength: "20" ``` HTTP protocol: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: deploymentName: rabbitmq-deployment triggers: - type: rabbitmq metadata: includeUnacked: "true" # Required apiHost: RabbitApiHost # references a value of format https://guest:password@localhost:443/vhostname queueName: testqueue queueLength: "20" ``` ================================================ FILE: content/docs/1.4/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: REDIS_HOST # Required host:port format password: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional ``` The `address` field in the spec holds the host and port of the redis server. This could be an external redis server or one running in the kubernetes cluster. As an alternative to the `address` field the user can specify `host` and `port` parameters. Provide the `password` field if the redis server requires a password. Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. The `listName` parameter in the spec points to the Redis List that you want to monitor. The `listLength` parameter defines the average target value for the Horizontal Pod Autoscaler (HPA). The `enableTLS` parameter if set to true allow a connection to a redis queue using tls, the default value for this parameter is false. The `databaseIndex` parameter let the user select the redis database to use. If not specified, the default value is 0 ### Authentication Parameters You can authenticate by using a password. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `password` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: deploymentName: votes triggers: - type: redis metadata: address: REDIS_ADDRESS listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/1.4/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/1.5/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/1.5/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates two custom resources: 1. `scaledobjects.keda.k8s.io` 1. `triggerauthentications.keda.k8s.io` These custom resources enable you to map an event source (and the authentication to that event source) to a deployment or job for scaling. The `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes deployment. A `ScaledObject` may also reference a `TriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/1.5/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use credentials or delegate authentication with `TriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/1.5/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: deploymentName: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `containerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.containerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.containerName of ScaledObject ``` **Assumptions:** `containerName` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none ``` #### Azure Pod Identity Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which let's you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: false ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set aadPodIdentity={your-label-name}`. #### AWS EKS Pod Identity Webhook [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: false ``` #### AWS Kiam Pod Identity [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: false ``` ================================================ FILE: content/docs/1.5/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interface: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#4-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#5-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates replicaCount based on metric value and target value. ### External Scaler GRPC interface KEDA comes with an external scaler [`external`](../scalers/external.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. Few things to notice: - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: deploymentName: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/1.5/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments" weight = 200 +++ ## Overview Deployments are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your deployment out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a deployment. Each replica of a deployment is actively pulling items from the event source. With KEDA and scaling deployments you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## ScaledObject spec This specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: deploymentName: {deployment-name} # must be in the same namespace as the ScaledObject containerName: {container-name} #Optional. Default: deployment.spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 triggers: # {list of triggers to activate the deployment} ``` You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: deploymentName: {deployment-name} # must be in the same namespace containerName: {container-name} #Optional. Default: deployment.spec.template.spec.containers[0] ``` The name of the deployment this scaledObject is for. This is the deployment KEDA will scale up and setup an HPA for based on the triggers defined in `triggers:`. Make sure to include the deployment name in the label as well, otherwise the metrics provider will not be able to query the metrics for the scaled object and 1-n scale will be broken. **Assumptions:** `deploymentName` is in the same namespace as the scaledObject. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the deployment up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the deployment back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment`, KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml minReplicaCount: 0 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the deployment down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given deployment. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/1.5/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. ## ScaledObject spec This specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleType: job jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job/) pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ================================================ FILE: content/docs/1.5/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/1.5/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 2** ```sh helm install keda kedacore/keda --version 1.5.0 --namespace keda --create-namespace ``` **Helm 3** ```sh kubectl create namespace keda helm install keda kedacore/keda --version 1.5.0 --namespace keda ``` > 💡 When using Helm 3.x, make sure to manually install the CRDs since Helm does not update nor add new CRDs. > Learn more about it on [kedacore/charts #139](https://github.com/kedacore/charts/issues/139). ### Uninstall If you want to remove KEDA from a cluster you can run one of the following: **Using Helm 3** ```sh helm uninstall -n keda keda kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml ``` **Using Helm 2** ```sh helm delete --purge keda kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator 2. Create namespace `keda` 3. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:**Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. We provide sample YAML declarations which includes our CRD in the released zip and tar.gz package files which are available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Download the zip or tar.gz file, unpack it, enter the unpacked folder and just run the following commands. ```sh kubectl apply -f ./crds kubectl apply -f ./ ``` You can also find the same YAML declarations in our `/deploy` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda && git checkout tags/v1.5.0 kubectl apply -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl apply -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml kubectl apply -f deploy/ ``` ### Uninstall You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh kubectl delete -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml kubectl delete -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml kubectl delete -f deploy/ ``` ================================================ FILE: content/docs/1.5/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq >}} ================================================ FILE: content/docs/1.5/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/1.5/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: # brokerList: kafka.svc:9092 - deprecated bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' ``` **Parameter list:** - `brokerList` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap (DEPRECATED). - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Topic on which processing the offset lag. - `lagThreshold` - How much the stream is lagging on the current consumer group. Default is 10. Optional. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing authMode, username, password. If your kafka cluster does not have sasl authentication turned on, you will not need to pay attention to it. **Credential based authentication:** - `authMode` - Kafka sasl auth mode. (Values: `none`, `sasl_plaintext`, `sasl_ssl`, `sasl_ssl_plain`, `sasl_scram_sha256`, `sasl_scram_sha512`. Default: `none`, Optional) - `username` - (Optional) - `password` - (Optional) - `ca` - Certificate authority file for TLS client authentication `sasl_ssl`. (Optional) - `cert` - Certificate for client authentication `sasl_ssl`. (Optional) - `key` - Key for client authentication with `sasl_ssl`. Optional) ### Example Your kafka cluster no sasl auth: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" ``` Your kafka cluster turn on sasl auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: authMode: "sasl_plaintext" username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: authMode name: keda-kafka-secrets key: authMode - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/1.5/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' ``` **Parameter list:** - `managementEndpoint` - "hostname:port" to connect to ActiveMQ Artemis management endpoint. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address name of the broker. - `queueLength` - How much messages are in the queue. (Default: `10`, Optional.) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis labels: deploymentName: kedartemis-consumer spec: scaleTargetRef: deploymentName: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/1.5/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyID: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKey: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/1.5/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/1.5/concepts/authentication/). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/1.5/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for `ApproximateNumberOfMessages` in the SQS Queue. (Default: `5`, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/1.5/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." notice = "As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connection: EVENTHUB_CONNECTIONSTRING_ENV_NAME # Connection string for Event Hub namespace appended with "EntityPath=" storageConnection: STORAGE_CONNECTIONSTRING_ENV_NAME # Connection string for account used to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. consumerGroup: $Default # Optional. Consumer group of event hub consumer. Default: $Default unprocessedEventThreshold: '64' # Optional. Target number of unprocessed events across all partitions in Event Hub for HPA. Default: 64 events. blobContainer: 'name_of_container' # Optional. Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function. ``` The `connection` value is the name of the environment variable your deployment uses to get the Event Hub connection string which is appended with the Event Hub name using Entity Path variable. `storageConnection` is the name of the environment variable your deployment uses to get the Storage connection string. Environment variables are usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required connection: EventHub storageConnection: AzureWebJobsStorage # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/1.5/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "1" activeDirectoryClientId: CLIENT_ID_ENV_NAME activeDirectoryClientPassword: CLIENT_PASSWORD_ENV_NAME ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource. The format is `"//"`. - `tenantId` - Tenant id for the Azure resource. Used for authentication. - `subscriptionId` - Subscription id for the Azure resource. Used for determining the full resource URI. - `resourceGroupName` - Resource group for the Azure resource. - `metricName` - Name of the Azure Monitor metric. Must be an officially supported metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Filter to define a more specific part of the resource. You can filter by supported dimensions of the metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Aggregation interval of the metric. Reported in the format `"mm:hh:ss"`. (Default: `"0:5:0"`, Optional) - `metricAggregationType` - Aggregation method of the Azure monitor metric. Some possible values include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). No default. - `targetValue` - Target value for the Azure metric to use in the HPA. - `activeDirectoryClientId` - Name of the environment variable that contains the active directory client id. Should have the RBAC role of `Monitoring Reader`. - `activeDirectoryClientPassword` - Name of the environment variable that contains the active directory client password. Should have the RBAC role of `Monitoring Reader`. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials. **Credential based authentication:** - `activeDirectoryClientId` - Active Directory client id. - `activeDirectoryClientPassword` - Active Directory client password. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler labels: app: azure-monitor-example spec: scaleTargetRef: deploymentName: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/1.5/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connection: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional queueLength: "5" # Optional. Subscription length target for HPA. Default: 5 messages ``` **Parameter list:** - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connection` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `queueLength` - Amount of active messages in your Azure Service Bus queue or topic to scale on. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional queueLength: "5" # default 5 authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/1.5/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by delete/move the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob # Required: Name of Azure Blob Storage container blobCount: '5' # Optional. Amount of blobs to scale out on. Default: 5 blobs connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Optional if TriggerAuthentication defined with pod identity or connection string authentication. blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "/" ``` The `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/1.5/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: functionsqueue queueLength: '5' # Optional. Queue length target for HPA. Default: 5 messages connection: STORAGE_CONNECTIONSTRING_ENV_NAME ``` The `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: deploymentName: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Required: connection OR authenticationRef that defines connection connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/1.5/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 30 * * * * # Every hour on the 30th minute end: 45 * * * * # Every hour on the 45th minute desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found in: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones. - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled between the start and end of the cron schedule. > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 30 * * * * > end: 30 * * * * >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: deploymentName: my-deployment triggers: - type: cron metadata: timezone: Asia/Kolkata start: 30 * * * * end: 45 * * * * desiredReplicas: "10" ``` ================================================ FILE: content/docs/1.5/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST # Required host:port format password: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required ``` > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: deploymentName: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/1.5/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentials` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: deploymentName: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ================================================ FILE: content/docs/1.5/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Dimension name of the metric. - `dimensionValue` - Dimension value of the metric. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Min value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric. Equivalent to the earliest start time of the end time. (Default: `300`, Optional) - `metricFilter` - Aggregation method of the metric. (Values: `max`, `min`, `average`, `sum`, `variance`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric. (Default: `300`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test labels: test: nginx-deployment spec: scaleTargetRef: deploymentName: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/1.5/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 # Address of the gRPC liiklus API endpoint group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # default 10, the target lag for HPA groupVersion: 1 # default 0, the groupVersion to consider when looking at messages. See https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java ``` ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: deploymentName: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/1.5/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionString` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `username` - Used to access MySQL database. - `password` - Used for the given user, this should be blank (no password) or point to an environment variable with the password. - `host` - Host of the database. - `port` - Port of the database. - `dbName` - As name of the database. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connection` - Connection string for MySQL database. **Password Authentication:** - `connection` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user@tcp(mysql:3306)/stats_db --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: deploymentName: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/1.5/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" # Location of the Nats Streaming monitoring endpoint queueGroup: "grp1" # Queue group name of the subscribers durableName: "ImDurable" # Must identify the durability name used by the subscribers subject: "Test" # Name of channel lagThreshold: "10" # Configures the TargetAverageValue on the Horizontal Pod Autoscaler (HPA)). ``` ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: deploymentName: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/1.5/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connection` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `password:` - Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string: ```yaml triggers: - type: postgresql metadata: connection: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" password: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: postgresql sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: deploymentName: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connection: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/1.5/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response ``` The `serverAddress` indicates where Prometheus is running which contains the configured metric defined in `metricName` or `query`. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: deploymentName: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` ================================================ FILE: content/docs/1.5/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: RabbitMqHost # Optional. If not specified, it must be done by using TriggerAuthentication. queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages queueName: testqueue includeUnacked: 'true' # Optional, use unacked + ready messages count apiHost: RabbitApiHost # Optional. Represents the HTTP management API endpoint. If not specified, it must be done by using TriggerAuthentication. authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` **Parameter list:** - `host` - Value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost`. - `queueName` - Name of the queue to read message from. - `queueLength` - Queue length target for HPA. (Default: `20`, Optional) - `includeUnacked` - By default, `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages. If `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count. `host` or `apiHost` value comes from authentication trigger. (Optional) - `apiHost` - It has similar format as of `host` but for HTTP API endpoint, like https://guest:password@localhost:443/vhostname. Note `host` and `apiHost` both have an optional vhost name after the host slash which will be used to scope API request. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - `host` - AMQP URI connection string, like `amqp://guest:password@localhost:5672/vhost`. - `apiHost` - HTTP API endpoint, like `https://guest:password@localhost:443/vhostname`. ### Example AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: deploymentName: rabbitmq-deployment triggers: - type: rabbitmq metadata: queueName: testqueue queueLength: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` HTTP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: apiHost: # base64 encoded value of format https://guest:password@localhost:443/vhostname --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: apiHost name: keda-rabbitmq-secret key: apiHost --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: deploymentName: rabbitmq-deployment triggers: - type: rabbitmq metadata: includeUnacked: "true" queueName: testqueue queueLength: "20" authenticationRef: name: rabbitmq-consumer-trigger ``` ================================================ FILE: content/docs/1.5/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: REDIS_HOST # Required host:port format password: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional ``` The `address` field in the spec holds the host and port of the redis server. This could be an external redis server or one running in the kubernetes cluster. As an alternative to the `address` field the user can specify `host` and `port` parameters. Provide the `password` field if the redis server requires a password. Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. The `listName` parameter in the spec points to the Redis List that you want to monitor. The `listLength` parameter defines the average target value for the Horizontal Pod Autoscaler (HPA). The `enableTLS` parameter if set to true allow a connection to a redis queue using tls, the default value for this parameter is false. The `databaseIndex` parameter let the user select the redis database to use. If not specified, the default value is 0 ### Authentication Parameters You can authenticate by using a password. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `password` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: deploymentName: votes triggers: - type: redis metadata: address: REDIS_ADDRESS listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/1.5/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: REDIS_SERVER # Required if host and port are not provided. Format - host:port host: REDIS_HOST # Required if address is not provided port: REDIS_PORT # Required if address is not provided and host has been provided password: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional ``` **Parameter list:** - `address` - Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - Name of the environment variable your deployment uses to get the Redis server host. - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. > It is not required if `address` has been provided.. - `port` - Name of the environment variable your deployment uses to get the Redis server port. - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. > It is only to be used along with the `host` attribute and not required if `address` has been provided. - `password` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters The scaler supports two modes of authentication: #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default labels: deploymentName: redis-streams-consumer spec: scaleTargetRef: deploymentName: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: REDIS_HOST password: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.k8s.io/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default labels: deploymentName: redis-streams-consumer spec: scaleTargetRef: deploymentName: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: REDIS_HOST stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/1.5/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.0/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.0/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.0/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.0/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.0/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.0/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.0/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.0/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.0/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates three custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.0/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use credentials or delegate authentication with `TriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.0/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.0/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interfaces: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. Few things to notice: - Lack of `Close` method as the GRPC connection defines the lifetime of the scaler - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` For `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.0/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v2.0.0/api/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml minReplicaCount: 0 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource. --- ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.0/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/v2.0.0/api/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcome of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of the length of the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.0/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.0/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) - [MicroK8s addon](#microk8s) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --version 2.0.0 --namespace keda --create-namespace ``` > 💡 Make sure to manually install the CRDs since Helm does not update nor add new CRDs. > Learn more about it on [kedacore/charts #139](https://github.com/kedacore/charts/issues/139). ### Uninstall If you want to remove KEDA from a cluster you can run one of the following: **Using Helm 3** ```sh helm uninstall -n keda keda kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.0.0/config/crd/bases/keda.sh_scaledobjects.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.0.0/config/crd/bases/keda.sh_scaledjobs.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.0.0/config/crd/bases/keda.sh_triggerauthentications.yaml ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.0.0`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.0.0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.0.0 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.0.0`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.0.0.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.0.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.0/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.0/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.0/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for it's Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.0/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) ================================================ FILE: content/docs/2.0/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.0 has been tested on Kubernetes v1.16.0 or above. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Operator | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | ---------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms, except for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 1 | While you can run multiple 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.This is only supported as of KEDA v2.6 if you are using our Helm chart. | ================================================ FILE: content/docs/2.0/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.0/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.0/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.0/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.0/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.0/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.0/concepts/authentication/). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.0/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual `ApproximateNumberOfMessages` in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.0/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." notice = "As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of event hub consumer. (Default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function. > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required connectionFromEnv: EventHub storageConnectionFromEnv: AzureWebJobsStorage # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.0/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. A data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (optional) - `metricAggregationInterval` - Collection time of the metric in format `"mm:hh:ss"` (default: `"0:5:0"` which is 5 minutes) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. Optional. Required when `TriggerAuthentication` is not provided. - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.0/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.0/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by delete/move the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.0/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.0/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.0/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.0/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.0/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.0/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.0/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.0/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Password Authentication:** - `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager. - `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.0/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.0/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.0/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many application implements basic auth with a username as apikey and password as empty. **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. This is a required field. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric must be json number type. The value is casted to **integer**. Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.0/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `password` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.0/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/2.0/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: postgresql sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.0/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Metric name to use. - `query` - Query to run. - `threshold` - Value to start scaling for. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` ================================================ FILE: content/docs/2.0/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: amqp # Specifies protocol to use, either amqp or http. Default value is amqp. queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages queueName: testqueue # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `amqp://:/`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20. Optional. - `protocol` - Protocol to be used for communication. Either `http` or `amqp`. It should correspond with the `host` value. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The connection string of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue queueLength: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue queueLength: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.0/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.0/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.0/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.1/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.1/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.1/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.1/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.1/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.1/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.1/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.1/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.1/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.1/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.1/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interfaces: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. Few things to notice: - Lack of `Close` method as the GRPC connection defines the lifetime of the scaler - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` For `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.1/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml minReplicaCount: 0 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource. --- ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.1/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.1/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.1/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) - [MicroK8s addon](#microk8s) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart ```sh helm install keda kedacore/keda --version 2.1.0 --namespace keda --create-namespace ``` > 💡 Make sure to manually install the CRDs since Helm does not update nor add new CRDs. > Learn more about it on [kedacore/charts #139](https://github.com/kedacore/charts/issues/139). ### Uninstall If you want to remove KEDA from a cluster you can run one of the following: ```sh helm uninstall -n keda keda kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_scaledobjects.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_scaledjobs.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_triggerauthentications.yaml kubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_clustertriggerauthentications.yaml ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.1.0`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.1.0/keda-2.1.0.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.1.0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.1.0 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.1.0`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.1.0/keda-2.1.0.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.1.0.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.1.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.1/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.1/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.1/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.1/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) ================================================ FILE: content/docs/2.1/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.1 has been tested on Kubernetes v1.16.0 or above. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Operator | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | ---------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms, except for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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.This is only supported as of KEDA v2.6 if you are using our Helm chart. | ## 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: ```shell export KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` And on Windows Powershell, you'd use this command: ```shell $env:KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` All applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported. ================================================ FILE: content/docs/2.1/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.1/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.1/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.1/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.1/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName dimensionName: QueueName # Required: Dimension Value - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Metric Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.1/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.1/concepts/authentication/). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.1/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual `ApproximateNumberOfMessages` in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.1/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." notice = "As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of event hub consumer. (Default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function. > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.1/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.1/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.1/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.1/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.1/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.1/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.1/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.1/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.1/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.1/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.1/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Password Authentication:** - `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager. - `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.1/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.1/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.1/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.1/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric must be json number type. The value is casted to **integer**. Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.1/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server with database used.It would be written like this "portnumber/dbname" port: "27017/test" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server with the `dbName` separated by slash `/`. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `password` - Password for the configured user to login to MongoDB server. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.1/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `password` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.1/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/2.1/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Required containerName: my-container # Required objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. This is needed due to Go URL parsing issues :sweat_smile: **Parameter list:** - `swiftURL` - The URL to query the Swift API. It must contain the hostname, the Swift port, the API version and the account ID. The pattern is: `http://://`. - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.1/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.1/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Metric name to use. - `query` - Query to run. - `threshold` - Value to start scaling for. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` ================================================ FILE: content/docs/2.1/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `amqp://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20. Optional. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue queueLength: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue queueLength: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.1/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.1/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.1/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.1/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.1/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.10/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.10/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.10/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.10/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.10/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.10/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). > Note, that you must "federate" the Azure AD Managed Identity (that the TriggerAuthentication `podIdentity.identityId` points to) with the 'subject' of the KEDA Operator service account. This will be similar to `system:serviceaccount:keda:keda-operator`. > 📝 The service account for the target deployment is not used here. ================================================ FILE: content/docs/2.10/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.10/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.10/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.10/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.10/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.10/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.10/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** ================================================ FILE: content/docs/2.10/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure | azure-workload # Required. identityId: # Optional vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. ``` #### Azure Pod Identity Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. #### AWS EKS Pod Identity Webhook [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` #### AWS Kiam Pod Identity [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.10/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.10/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: ([Experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features)) Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics (Experimental)"](#caching-metrics-experimental). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Caching Metrics (Experimental) This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This is an [experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features). This feature is not supported for `cpu`, `memory` or `cron` scaler. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" ``` The presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition. ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.10/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.10/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.10/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.10.1`, with the one you are using): ```sh # Including admission webhooks kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1.yaml # Without admission webhooks kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply -f keda-2.10.1.yaml # Without admission webhooks kubectl apply -f keda-2.10.1-core.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.10.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.10.1`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.10.1.yaml # Without admission webhooks kubectl delete -f keda-2.10.1-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.10.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.10/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.10/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). - `keda_trigger_totals` - Total number of triggers per trigger type. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server > 💡 **DEPRECATED:** Prometheus Metrics exposed from Metrics Server are deprecated, please consume metrics from KEDA Operator. The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaler - metric ================================================ FILE: content/docs/2.10/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.10/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.10/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. ================================================ FILE: content/docs/2.10/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | -------------- | ------------- | ----------------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | | KEDA_METRICS_CTRL_MAX_RECONCILES | Metrics Server | 1 | MetricsScaledObjectReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.10/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.10/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.10/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). The KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). ================================================ FILE: content/docs/2.10/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.10/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.10/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.10/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.10/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.10/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.10/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.10/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.10/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.10/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.10/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. - `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well. - When set to `false` "actual messages" is equal to `ApproximateNumberOfMessages`. When set to `true` "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.10/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.10/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well clientSecret: t0p-s3cret # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `clientSecret` - Password of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.10/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.10/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId. DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.10/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ###Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ================================================ FILE: content/docs/2.10/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.10/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.10/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.10/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" metricName: "test_keyspace" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `metricName` - Name to assign to the metric. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.10/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" metricName: "global-metric" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.10/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.10/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.10/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ## Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. ### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. ### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ## Cases of unexpected metrics value in DataDog API response ### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue ### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.10/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.10/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.10/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.10/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.10/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5.5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge activationValue: "10.5" # Optional - Default is 0 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. You can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`. The mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`. The `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.10/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.10/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.10/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 authenticationRef: name: personalAccessToken ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.10/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric, DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.10/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.10/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.10/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.10/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.10/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.10/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.10/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.10/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.10/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.10/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.10/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.10/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.10/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.10/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.10/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.10/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.10/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.10/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.10/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below) customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. **Azure Monitor managed service for Prometheus** Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure | azure-workload # use "azure" for pod identity and "azure-workload" for workload identity identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` ================================================ FILE: content/docs/2.10/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`,`basic`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` ================================================ FILE: content/docs/2.10/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.10/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.10/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.10/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.10/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.10/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.10/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.10/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional platformName: 'Linux' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.10/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) activationMessageCountTarget: '100' activationMessageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.10/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.11/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.11/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.11/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.11/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.11/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.11/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). > Note, that you must "federate" the Azure AD Managed Identity (that the TriggerAuthentication `podIdentity.identityId` points to) with the 'subject' of the KEDA Operator service account. This will be similar to `system:serviceaccount:keda:keda-operator`. > 📝 The service account for the target deployment is not used here. ================================================ FILE: content/docs/2.11/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.11/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.11/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.11/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.11/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.11/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.11/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) ================================================ FILE: content/docs/2.11/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. ``` #### Azure Pod Identity Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. #### AWS EKS Pod Identity Webhook [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` #### AWS Kiam Pod Identity [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.11/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.11/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject autoscaling.keda.sh/paused-replicas: "0" # Optional. Use to pause autoscaling of objects spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" ``` The presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition. ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transfer ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.11/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### Pause autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. This is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again. You can enable this by adding the below annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` The above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.11/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.11/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.11.2`, with the one you are using): ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.11.2.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.11.2-core.yaml ``` > 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details. - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.11.2 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.11.2`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.11.2.yaml # Without admission webhooks kubectl delete -f keda-2.11.2-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.11.2 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.11/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.11/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). - `keda_trigger_totals` - Total number of triggers per trigger type. - `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaler - metric ================================================ FILE: content/docs/2.11/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.11/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.11/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. ================================================ FILE: content/docs/2.11/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.11/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.11/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (just an external metric): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query an specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.11/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). The KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). ================================================ FILE: content/docs/2.11/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.11/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.11/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.11/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.11/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.11/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.11/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.11/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.11/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.11/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.11/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. - `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well. - When set to `false` "actual messages" is equal to `ApproximateNumberOfMessages`. When set to `true` "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.11/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.11/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well clientSecret: t0p-s3cret # DEPRECATED, use TriggerAuthentication or clientSecretFromEnv # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `clientSecret` - Password of the Azure AD application. (DEPRECATED: This parameter is deprecated as of KEDA v2.11 and will be removed in version `2.13`) - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.11/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.11/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId. DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.11/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ###Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ================================================ FILE: content/docs/2.11/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.11/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.11/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.11/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" metricName: "test_keyspace" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `metricName` - Name to assign to the metric. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.11/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" metricName: "global-metric" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.11/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.11/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.11/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ## Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. ### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. ### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ## Cases of unexpected metrics value in DataDog API response ### Latest data point is unavailable By default Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue ### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.11/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.11/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.11/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.11/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.11/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5.5" # Optional - Default is 10 activationValue: "10.5" # Optional - Default is 0 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the camel case of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metric starts with `subscription/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.11/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.11/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.11/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.11/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric, DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.11/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.11/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.11/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.11/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.11/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.11/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.11/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.11/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.11/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.11/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.11/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.11/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.11/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.11/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.11/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.11/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.11/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.11/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.11/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below) customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. **Azure Monitor managed service for Prometheus** Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. **Google Managed for Prometheus:** Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure | azure-workload # use "azure" for pod identity and "azure-workload" for workload identity identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.11/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`,`basic`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` ================================================ FILE: content/docs/2.11/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter unsafeSsl: true ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.11/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.11/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.11/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.11/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.11/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "mymaster" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.11/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.11/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional platformName: 'Linux' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.11/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.11/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.11/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.12/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.12/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.12/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.12/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.12/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.12/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). > Note, that you must "federate" the Azure AD Managed Identity (that the TriggerAuthentication `podIdentity.identityId` points to) with the 'subject' of the KEDA Operator service account. This will be similar to `system:serviceaccount:keda:keda-operator`. > 📝 The service account for the target deployment is not used here. ================================================ FILE: content/docs/2.12/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.12/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.12/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.12/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.12/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.12/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.12/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.12/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. ``` #### Azure Pod Identity Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. #### AWS EKS Pod Identity Webhook [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` #### AWS Kiam Pod Identity [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.12/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.12/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject autoscaling.keda.sh/paused-replicas: "0" # Optional. Use to pause autoscaling of objects autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ##### `scalingModifiers` The `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. ###### `scalingModifiers.target` `target` defines new target value to scale on for the composed metric. ###### `scalingModifiers.activationTarget` `activationTarget` defines new [activation target value](./scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) ###### `scalingModifiers.metricType` `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) ###### `scalingModifiers.formula` `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](#scaling-modifiers-experimental) below. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To enable/unpause autoscaling again, simply remove all paused annotations from the `ScaledObject` definition. ### Scaling Modifiers (Experimental) **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "float(trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0)" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean) ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transfer ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.12/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### Pause autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. This is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again. You can enable this by adding the below annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` The above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.12/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.12/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` To deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page. > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.12.1`, with the one you are using): ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.12.1.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.12.1-core.yaml ``` > 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details. - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.12.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.12.1`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.12.1.yaml # Without admission webhooks kubectl delete -f keda-2.12.1-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.12.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.12/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.12/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector using HTTP. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in|active (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.12/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). - `keda_trigger_totals` - Total number of triggers per trigger type. - `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaler - metric ================================================ FILE: content/docs/2.12/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.12/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.12/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. ================================================ FILE: content/docs/2.12/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.12/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.12/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (just an external metric): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.12/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). ================================================ FILE: content/docs/2.12/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.12/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.12/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.12/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.12/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.12/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.12/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.12/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.12/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.12/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.12/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.12/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.12/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.12/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well clientSecret: t0p-s3cret # DEPRECATED, use TriggerAuthentication or clientSecretFromEnv # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `clientSecret` - Password of the Azure AD application. (DEPRECATED: This parameter is deprecated as of KEDA v2.11 and will be removed in version `2.13`) - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.12/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.12/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.12/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) - > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ###Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ================================================ FILE: content/docs/2.12/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](./../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.12/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.12/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.12/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.12/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.12/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.12/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.12/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ## Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. ### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. ### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ## Cases of unexpected metrics value in DataDog API response ### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue ### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.12/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.12/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.12/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.12/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.12/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform‎ Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform‎ Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.12/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5.5" # Optional - Default is 10 activationValue: "10.5" # Optional - Default is 0 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the camel case of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metric starts with `subscription/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.12/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.12/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.12/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.12/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.12/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.12/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.12/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.12/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.12/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.12/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.12/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.12/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.12/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.12/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.12/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.12/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.12/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.12/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.12/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.12/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.12/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.12/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.12/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below) customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. **Azure Monitor managed service for Prometheus** Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. **Google Managed for Prometheus:** Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure | azure-workload # use "azure" for pod identity and "azure-workload" for workload identity identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.12/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: ``` ================================================ FILE: content/docs/2.12/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter unsafeSsl: true ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.12/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.12/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.12/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.12/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.12/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "mymaster" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.12/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.12/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional platformName: 'Linux' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.12/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.12/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.12/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.13/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.13/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.13/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.13/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. > ⚠️ **WARNING:** `aws-kiam` auth has been deprecated given [AWS KIAM is no longer maintained](https://github.com/uswitch/kiam/#-%EF%B8%8Fthis-project-is-now-being-abandoned-%EF%B8%8F-). As a result, [support for it will be removed from KEDA on v2.15](https://github.com/kedacore/keda/discussions/5342). We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.13/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.13/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication uses automatically both, doing a fallback from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html), you just need to add KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a a basic configuration for an IRSA role. The policy changes depend if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure This is the easiest case and you just need to attach to KEDA's role the desired policy/policies, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.13/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. > ⚠️ **WARNING:** [Azure AD Pod Identity was archived](https://github.com/Azure/aad-pod-identity#-announcement) and support for it will be removed from KEDA on v2.15. We strongly encourage the migration to [Azure Workload Identity](https://azure.github.io/azure-workload-identity). You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.13/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ================================================ FILE: content/docs/2.13/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.13/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.13/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.13/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.13/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.13/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.13/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.13/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.13/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.13/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | azure-workload | aws | aws-eks | aws-kiam # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Pod Identity > [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5362) Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` #### AWS Kiam Pod Identity > [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5342) [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.13/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.13/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject autoscaling.keda.sh/paused-replicas: "0" # Optional. Use to pause autoscaling of objects autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig:` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ##### `scalingModifiers` The `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. ###### `scalingModifiers.target` `target` defines new target value to scale on for the composed metric. ###### `scalingModifiers.activationTarget` `activationTarget` defines new [activation target value](./scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) ###### `scalingModifiers.metricType` `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) ###### `scalingModifiers.formula` `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](#scaling-modifiers-experimental) below. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To enable/unpause autoscaling again, simply remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can also set the annotation to `false` to unpause. ### Scaling Modifiers (Experimental) **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transfer ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.13/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### Pause autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. This is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again. You can enable this by adding the below annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` The above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition or set the value to `false`. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.13/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.13/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` To deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page. > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.13.1`, with the one you are using): ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.13.1.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.13.1-core.yaml ``` > 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details. - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.13.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.13.1`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.13.1.yaml # Without admission webhooks kubectl delete -f keda-2.13.1-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.13.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.13/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.13/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector using HTTP. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | ================================================ FILE: content/docs/2.13/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). - `keda_trigger_totals` - Total number of triggers per trigger type. - `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.13/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.13/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.13/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. ================================================ FILE: content/docs/2.13/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.13/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source| | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1| | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1| | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0| | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added| | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted| | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added| | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted| | ## CloudEvent Support (Experimental) ### Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. destination: http: uri: http://foo.bar ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ### Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). #### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Supported Event List | Event Type | Scenario Description | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | ================================================ FILE: content/docs/2.13/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (just an external metric): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.13/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). ================================================ FILE: content/docs/2.13/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.13/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.13/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.13/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.13/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.13/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.13/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.13/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.13/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.13/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.13/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.13/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.13/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.13/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.13/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.13/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.13/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.13/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](./../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.13/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.13/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.13/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.13/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.13/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.13/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.13/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ## Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. ### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. ### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ## Cases of unexpected metrics value in DataDog API response ### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue ### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.13/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.13/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.13/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.13/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.13/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform‎ Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform‎ Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.13/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 activationValue: "10.5" # Optional - Default is 0 # Either one of subscriptionName or topicName is required subscriptionName: "mysubscription" topicName: "mytopic" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.13/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.13/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.13/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.13/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.13/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.13/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.13/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.13/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.13/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.13/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.13/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.13/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.13/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.13/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.13/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.13/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.13/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.13/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.13/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.13/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.13/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.13/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.13/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below) customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure | azure-workload # use "azure" for pod identity and "azure-workload" for workload identity identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.13/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.13/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter unsafeSsl: true ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.13/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.13/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.13/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.13/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.13/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "mymaster" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.13/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.13/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional platformName: 'Linux' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.13/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.13/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.13/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.14/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.14/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.14/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.14/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. > ⚠️ **WARNING:** `aws-kiam` auth has been deprecated given [AWS KIAM is no longer maintained](https://github.com/uswitch/kiam/#-%EF%B8%8Fthis-project-is-now-being-abandoned-%EF%B8%8F-). As a result, [support for it will be removed from KEDA on v2.15](https://github.com/kedacore/keda/discussions/5342). We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.14/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.14/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication uses automatically both, doing a fallback from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html), you just need to add KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a a basic configuration for an IRSA role. The policy changes depend if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure This is the easiest case and you just need to attach to KEDA's role the desired policy/policies, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.14/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. > ⚠️ **WARNING:** [Azure AD Pod Identity was archived](https://github.com/Azure/aad-pod-identity#-announcement) and support for it will be removed from KEDA on v2.15. We strongly encourage the migration to [Azure Workload Identity](https://azure.github.io/azure-workload-identity). You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.14/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.14/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.14/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.14/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.14/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.14/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.14/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.14/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.14/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.14/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.14/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | azure-workload | aws | aws-eks | aws-kiam # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Pod Identity > [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5362) Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` #### AWS Kiam Pod Identity > [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5342) [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.14/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.14/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`. By default, this is 0 seconds, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig:` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ##### `scalingModifiers` The `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. ###### `scalingModifiers.target` `target` defines new target value to scale on for the composed metric. ###### `scalingModifiers.activationTarget` `activationTarget` defines new [activation target value](./scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) ###### `scalingModifiers.metricType` `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) ###### `scalingModifiers.formula` `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](#scaling-modifiers-experimental) below. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To enable/unpause autoscaling again, simply remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can also set the annotation to `false` to unpause. ### Scaling Modifiers (Experimental) **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transfer ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disable validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.14/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### Pause autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. This is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again. You can enable this by adding the below annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` The above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition or set the value to `false`. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.14/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.14/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` To deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page. > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.14.1`, with the one you are using): ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.14.1.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.14.1-core.yaml ``` > 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details. - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.14.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.14.1`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.14.1.yaml # Without admission webhooks kubectl delete -f keda-2.14.1-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.14.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.14/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.14/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.14/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.14/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. Replaced by `keda_scaler_metrics_latency_seconds`. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. Replaced by `keda_scaler_detail_errors_total`. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. Replaced by `keda_scaler_detail_errors_total`. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. Replaced by `keda_scaled_object_errors_total`. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). Replaced by `keda_resource_registered_total`. - `keda_trigger_totals` - Total number of triggers per trigger type. Replaced by `keda_trigger_registered_total`. - `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. Replaced by `keda_internal_scale_loop_latency_seconds`. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.14/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.14/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.14/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ================================================ FILE: content/docs/2.14/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | ================================================ FILE: content/docs/2.14/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.14/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source| | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...}| | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1| | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0| | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added| | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted| | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added| | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted| | ## CloudEvent Support (Experimental) ### Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ### Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). #### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` #### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: ##### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. ##### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ### Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ### Supported Event List | Event Type | Scenario Description | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | ================================================ FILE: content/docs/2.14/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (just an external metric): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.14/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`). ================================================ FILE: content/docs/2.14/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.14/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | | ================================================ FILE: content/docs/2.14/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_14" >}} ================================================ FILE: content/docs/2.14/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## GRPC Go Remote Procedure Call. An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.14/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.14/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ### scalingModifiers The `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md#scaling-modifiers-experimental). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.14/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.14/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.14/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.14/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.14/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.14/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.14/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.14/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.14/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.14/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.14/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.14/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.14/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.14/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.14/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.14/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.14/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](./../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.14/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.14/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.14/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.14/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.14/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.14/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.14/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ## Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. ### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. ### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ## Cases of unexpected metrics value in DataDog API response ### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue ### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.14/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.14/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.14/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.14/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.14/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.14/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 activationValue: "10.5" # Optional - Default is 0 # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.14/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.14/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.14/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.14/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.14/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.14/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.14/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.14/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.14/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.14/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.14/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.14/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.14/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.14/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.14/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.14/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.14/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. **TLS Authentication** - `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### Example without any TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with no TLS ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` #### Example with TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-stan-secrets namespace: default data: tls: enable ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: default spec: secretTargetRef: - parameter: tls name: keda-stan-secrets key: tls - parameter: ca name: keda-stan-secrets key: ca - parameter: cert name: keda-stan-secrets key: cert - parameter: key name: keda-stan-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "true" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.14/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.14/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.14/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.14/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.14/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.14/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below) customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure | azure-workload # use "azure" for pod identity and "azure-workload" for workload identity identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.14/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.14/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter unsafeSsl: true ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.14/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.14/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.14/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.14/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.14/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "mymaster" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.14/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.14/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional platformName: 'Linux' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.14/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.14/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.14/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.14/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.15/_index.md ================================================ +++ title = "Getting Started" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation bar on the left to learn more about KEDA's architecture and how to deploy and use KEDA. ## Where to go What is your involvement with KEDA? | Role | Documentation | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | User | This documentation is for users who want to deploy KEDA to scale Kubernetes. | | Core Contributor | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda). | | Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). | | Other Contributor | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers. | ================================================ FILE: content/docs/2.15/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.15/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.15/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.15/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure Attach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.15/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.15/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.15/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.15/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.15/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.15/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.15/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.15/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.15/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.15/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.15/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.15/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.15/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ This page describes the deployment scaling behavior of KEDA. # Specification See the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below. # Scaling objects ## Scaling Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## Scaling Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). # Features ## Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ## Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`. ## Scaling Modifiers **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ## Activating and Scaling thresholds KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transferring ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disabling validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ### Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. #### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. #### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](./scaling-jobs). ================================================ FILE: content/docs/2.15/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ This page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below. # Overview As an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` # Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` To reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`. ```yaml metadata: annotations: autoscaling.keda.sh/paused: false ``` ## Example An example configuration for autoscaling jobs using a RabbitMQ scaler is given below. ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.15/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.15/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - Helm charts - Operator Hub - YAML declarations > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install To deploy KEDA with Helm: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` To deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page. > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.15.1`, with the one you are using): ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.15.1.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.15.1-core.yaml ``` > 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details. - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.15.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.15.1`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.15.1.yaml # Without admission webhooks kubectl delete -f keda-2.15.1-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.15.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s add-ons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, disable the add-on as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.15/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.15/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.15/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.15/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). > Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed. #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. Replaced by `keda_scaler_metrics_latency_seconds`. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. Replaced by `keda_scaler_detail_errors_total`. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. Replaced by `keda_scaler_detail_errors_total`. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. Replaced by `keda_scaled_object_errors_total`. - `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob. Replace by `keda_scaled_job_errors_total`. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). Replaced by `keda_resource_registered_total`. - `keda_trigger_totals` - Total number of triggers per trigger type. Replaced by `keda_trigger_registered_total`. - `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. Replaced by `keda_internal_scale_loop_latency_seconds`. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.15/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.15/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance and requirements for operating KEDA" weight = 1 +++ We provide guidance and requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](../reference/events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.15/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ## Custom Validations using Kubernetes ValidatingAdmissionPolicy > ⚠️ FEATURE STATE: Kubernetes v1.30 [stable] Kubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). Here is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10): ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-keda-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["keda.sh"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["scaledobjects"] validations: - expression: "object.spec.maxReplicaCount <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-keda-replicas-binding.example.com" spec: policyName: "limit-keda-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` Since KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas: ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-apps-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments", "replicasets"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-hpa-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["autoscaling"] apiVersions: ["v2"] operations: ["CREATE", "UPDATE"] resources: ["horizontalpodautoscalers"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-apps-replicas-binding.example.com" spec: policyName: "limit-apps-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-hpa-replicas-binding.example.com" spec: policyName: "limit-hpa-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` ================================================ FILE: content/docs/2.15/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ### Scopes: Namespace vs. Cluster Each `CloudEventSource` is defined in one namespace and will only subscribe to events inside that namespace. If you want to subscribe to events in all namespaces, you can instead create a `ClusterCloudEventSource` resource. Defining a `ClusterCloudEventSource` works almost identically to a `CloudEventSource`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterCloudEventSource metadata: name: {cluster-cloudeventsource-name} spec: # As before .. ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | | `keda.scaledobject.removed.v1`| When a ScaledObject is deleted | ================================================ FILE: content/docs/2.15/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.15/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (external metrics only): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.15/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory. Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`. ================================================ FILE: content/docs/2.15/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.15/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | | ================================================ FILE: content/docs/2.15/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_15" >}} ================================================ FILE: content/docs/2.15/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## gRPC Remote Procedure Calls (gRPC) gRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.15/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale `Job` resources. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). **eager** When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible. For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours. ### pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: rabbitmq metadata: queueName: woker_queue hostFromEnv: RABBITMQ_URL mode: QueueLength value: "1" ``` We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 3 | If we switch to `eager`, the result becomes: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 6 | We can identify the difference in their final states. You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.15/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ### scalingModifiers If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.15/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.15/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.15/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.15/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.15/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Datastore" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.15/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.15/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.15/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.15/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.15/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.15/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.15/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.15/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.15/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) > When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.15/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides ### Links - [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) - [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity) - [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity) ================================================ FILE: content/docs/2.15/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "0.5" activationTargetValue: "3.5" activeDirectoryClientId: # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.15/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not use demands in your agent scaler then it scales based on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.15/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.15/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.15/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' queueLengthStrategy: all|visibleonly activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 # Optional queueLengthStrategy: "all" # or visibleonly. Default: all cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.15/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. - `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional). - `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional) - `key` - Key path for client authentication. Mandatory if tls enabled. (Optional) ### Example with no TLS auth ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ### Example with TLS auth Since we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes: - name: temp-cassandra-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes.keda.extraVolumes - name: temp-cassandra-vol emptyDir: medium: Memory ``` Once we have the writable mount path set up for the certificates and keys. ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD tls: enable cert: key: ## Optional parameter ca ## ca: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password - parameter: tls name: cassandra-secrets key: tls - parameter: cert name: cassandra-secrets key: cert - parameter: key name: cassandra-secrets key: key ## Optional parameter ca ## - parameter: ca name: cassandra-secrets key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.15/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.15/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.15/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.15/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). There are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately. ## Using the Datadog Cluster Agent (Experimental) With this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches. ### Deploy the Datadog Cluster Agent with enabled external metrics First, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA). If you are using Helm to deploy the Cluster Agent, set: * `clusterAgent.metricsProvider.enabled` to `true` * `clusterAgent.metricsProvider.registerAPIService` to `false` * `clusterAgent.metricsProvider.useDatadogMetrics` to `true` * `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}]` If you are using the Datadog Operator, add the following options to your `DatadogAgent` object: ``` apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: name: datadog spec: features: externalMetricsServer: enabled: true useDatadogMetrics: true registerAPIService: false override: clusterAgent: env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}] [...] ``` NOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later. ### Create a DatadogMetric object for each scaling query To use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: "true"` annotation, to ensure the Cluster Agent retrieves the query value. Example: ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: annotations: external-metrics.datadoghq.com/always-active: "true" name: nginx-hits spec: query: sum:nginx.net.request_per_s{kube_deployment:nginx} ``` ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType metricUnavailableValue: "1.5" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional) - `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events. - `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events. - `targetValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication The Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Common to all authentication types** - `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional) - `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed. - `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern. - `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional) **Bearer authentication:** - `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-config namespace: my-project type: Opaque data: datadogNamespace: # Required: base64 encoded value of the namespace where the Datadog Cluster Agent is deployed datadogMetricsService: # Required: base64 encoded value of the Cluster Agent metrics server service unsafeSsl: # Optional: base64 encoded value of `true` or `false` authMode: # Required: base64 encoded value of the authentication mode (in this case, bearer) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: datadog-cluster-agent-creds namespace: my-project spec: secretTargetRef: - parameter: token name: dd-cluster-agent-token key: token - parameter: datadogNamespace name: datadog-config key: datadogNamespace - parameter: unsafeSsl name: datadog-config key: unsafeSsl - parameter: authMode name: datadog-config key: authMode - parameter: datadogMetricsService name: datadog-config key: datadogMetricsService --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx maxReplicaCount: 3 minReplicaCount: 1 pollingInterval: 60 triggers: - type: datadog metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "2" type: "global" authenticationRef: name: datadog-cluster-agent-creds ``` ## Using the Datadog REST API ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "false" query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false) - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ### Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../reference/scaledobject-spec/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ### Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. #### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. #### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ### Cases of unexpected metrics value in DataDog API response #### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue #### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.15/scalers/dynatrace.md ================================================ +++ title = "Dynatrace" availability = "2.15+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Dynatrace metric data points" go_file = "dynatrace_scaler" +++ ### Trigger Specification This specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points. ```yaml triggers: - type: dynatrace metadata: host: https://dummy-instance.live.dynatrace.com/ metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' # Optional from: now-2d threshold: "10" # Optional activationThreshold: "5" ``` **Parameter list:** - `host` - The Dynatrace instance to query against - `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). Some relevant aspects: - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector - `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters. **Authentication:** - `host` - The Dynatrace instance to query against - `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/ token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' from: 'now-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ================================================ FILE: content/docs/2.15/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.15/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.15/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.15/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.15/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 filterDuration: '1' # Optional - Default is 2 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.15/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 valueIfNull: '0.0' # Optional - Default is "" activationValue: "10.5" # Optional - Default is 0 timeHorizon: "1m" # Optional - Default is 2m and with aggregation 5m # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`) - `valueIfNull` - Value returned if request returns no timeseries.(Default: `""`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.15/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" filterDuration: '1' # Optional - Default is 2 activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.15/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.15/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.15/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.15/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.15/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret unsafeSsl: # OPTIONAL - Set 'true' for unsafe SSL. Default: false ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example Example with Basic Auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ### Example Example with Basic Auth and TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password cert: key: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD - parameter: cert name: keda-ibmmq-secret key: cert - parameter: key name: keda-ibmmq-secret key: key ``` ================================================ FILE: content/docs/2.15/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.15/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.15/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.15/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.15/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.15/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.15/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.15/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.15/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.15/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.15/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. **TLS Authentication** - `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### Example without any TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with no TLS ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` #### Example with TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-stan-secrets namespace: default data: tls: enable ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: default spec: secretTargetRef: - parameter: tls name: keda-stan-secrets key: tls - parameter: ca name: keda-stan-secrets key: ca - parameter: cert name: keda-stan-secrets key: cert - parameter: key name: keda-stan-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "true" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.15/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.15/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.15/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.15/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for three connection options: A user can offer a full connection string (often in the form of an environment variable secret). - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. It is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity. More details and an example are provided down below. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` **Azure Access Token authentication:** #### Prerequisites: - The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity). - The UAMI should be granted access to the table mentioned in the query performed by KEDA. This can be achieved by: - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role. - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like `GRANT ALL ON TO "";`. Next, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process. - `host` - FQDN of the Azure Postgres Flexible Server. - `userName` - Name of the UAMI Azure identity (``). - `port` - Postgresql port (the default value is `"5432"`, please have a look at the `Remarks` down below). - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database (the value should be `require`). #### Remarks - While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-pg-flex-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql authenticationRef: name: azure-pg-flex-auth metadata: host: port: "5432" userName: dbName: sslmode: require query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.15/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.15/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.15/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.15/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter unsafeSsl: true ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.15/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.15/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.15/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.15/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.15/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "myprimary" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.15/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.15/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional platformName: 'Linux' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.15/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.15/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.15/scalers/splunk.md ================================================ +++ title = "Splunk" availability = "v2.15+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk saved search results." go_file = "splunk_scaler" +++ ### Trigger Specification This specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches). The trigger always requires the following information: ```yaml triggers: - type: splunk metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "1" activationValue: "10" savedSearchName: my-saved-search-name valueField: count ``` **Parameter list:** - `host` - Search API host and port. Example: `https://localhost:8089`. - `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `"true"`, `"false"`, Default: `"false"`, Optional) - `targetValue` - Value to reach to start scaling (This value can be a integer or float). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `savedSearchName` - Name of saved search that returns metric data for scaling. - `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`. ### Authentication Parameters You can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication. > **Note:** > > `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API. **Parameter list:** - `username` - Splunk username authorized to access the search API. - `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`. - `password` - Password for supplied `username`. Conflicts with `apiToken`. The user will need access to the saved search. ### Examples ### Username/password ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### API Token ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # admin apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: apiToken name: splunk-creds key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### Full example using Splunk deployment ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: splunkconf data: default.yml: | splunk: conf: - key: savedsearches value: directory: /opt/splunk/etc/users/admin/search/local content: my-saved-search-name: action.email.useNSSubject: 1 action.webhook.enable_allowlist: 0 alert.track: 0 cron_schedule: '*/1 * * * *' dispatch.earliest_time: -15m dispatch.latest_time: now display.general.type: statistics display.page.search.tab: statistics display.visualizations.show: 0 enableSched: 1 request.ui_dispatch_app: search request.ui_dispatch_view: search search: index=_internal | tail | stats count --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: v1 kind: Service metadata: name: splunk spec: ports: - port: 8000 targetPort: web name: web-svc - port: 8089 targetPort: 8089 name: api-svc selector: app: splunk --- apiVersion: apps/v1 kind: Deployment metadata: name: splunk namespace: default spec: replicas: 1 selector: matchLabels: app: splunk template: metadata: labels: app: splunk spec: containers: - name: splunk image: splunk/splunk:9.2 ports: - containerPort: 8000 name: web - containerPort: 8089 name: api env: - name: SPLUNK_START_ARGS value: --accept-license - name: SPLUNK_PASSWORD value: password volumeMounts: - name: splunkconf-volume mountPath: /tmp/defaults volumes: - name: splunkconf-volume configMap: name: splunkconf --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8080 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 unsafeSsl: "true" targetValue: "5" activationValue: "5" savedSearchName: my-saved-search-name valueField: count ``` ================================================ FILE: content/docs/2.15/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.15/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.16/_index.md ================================================ +++ title = "Getting Started" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation bar on the left to learn more about KEDA's architecture and how to deploy and use KEDA. ## Where to go What is your involvement with KEDA? | Role | Documentation | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | User | This documentation is for users who want to deploy KEDA to scale Kubernetes. | | Core Contributor | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda). | | Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). | | Other Contributor | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers. | ================================================ FILE: content/docs/2.16/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.16/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.16/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.16/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure Attach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.16/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.16/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.16/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.16/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.16/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.16/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.16/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.16/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.16/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs three key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. 3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.16/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.16/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.16/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.16/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ This page describes the deployment scaling behavior of KEDA. # Specification See the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below. # Scaling objects ## Scaling Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## Scaling Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). # Features ## Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval. Enabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ## Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`. ## Scaling Modifiers **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ## Activating and Scaling thresholds KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transferring ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disabling validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ### Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. #### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. #### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](./scaling-jobs). ================================================ FILE: content/docs/2.16/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ This page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below. # Overview As an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` # Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` To reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`. ```yaml metadata: annotations: autoscaling.keda.sh/paused: false ``` ## Example An example configuration for autoscaling jobs using a RabbitMQ scaler is given below. ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.16/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.16/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - Helm charts - Operator Hub - YAML declarations > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install To deploy KEDA with Helm: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` To deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page. > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. - We offer two options to deploy KEDA: - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended) - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks Run the following command (if needed, replace the version, in this case `2.16.1`, with the one you are using): ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1-core.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.16.1.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.16.1-core.yaml ``` > 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details. - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.16.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.16.1`, with the one you are using): ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1-core.yaml ``` - If you have downloaded the file locally, you can run: ```sh # Including admission webhooks kubectl delete -f keda-2.16.1.yaml # Without admission webhooks kubectl delete -f keda-2.16.1-core.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.16.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s add-ons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, disable the add-on as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.16/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.16/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.16/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.16/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). > Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed. #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. - `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. Replaced by `keda_scaler_metrics_latency_seconds`. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. Replaced by `keda_scaler_detail_errors_total`. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. Replaced by `keda_scaler_detail_errors_total`. - `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. Replaced by `keda_scaled_object_errors_total`. - `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob. Replace by `keda_scaled_job_errors_total`. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). Replaced by `keda_resource_registered_total`. - `keda_trigger_totals` - Total number of triggers per trigger type. Replaced by `keda_trigger_registered_total`. - `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. Replaced by `keda_internal_scale_loop_latency_seconds`. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.16/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.16/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance and requirements for operating KEDA" weight = 1 +++ We provide guidance and requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](../reference/events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.16/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ### Cache Miss with Fallback to Direct Client for ScaledObject When validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`: ``` --cache-miss-to-direct-client=true ``` This will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API. ## Custom Validations using Kubernetes ValidatingAdmissionPolicy > ⚠️ FEATURE STATE: Kubernetes v1.30 [stable] Kubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). Here is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10): ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-keda-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["keda.sh"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["scaledobjects"] validations: - expression: "object.spec.maxReplicaCount <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-keda-replicas-binding.example.com" spec: policyName: "limit-keda-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` Since KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas: ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-apps-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments", "replicasets"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-hpa-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["autoscaling"] apiVersions: ["v2"] operations: ["CREATE", "UPDATE"] resources: ["horizontalpodautoscalers"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-apps-replicas-binding.example.com" spec: policyName: "limit-apps-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-hpa-replicas-binding.example.com" spec: policyName: "limit-hpa-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` ================================================ FILE: content/docs/2.16/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | | `keda.scaledobject.removed.v1`| When a ScaledObject is deleted | | `keda.scaledjob.ready.v1`| On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledjob.failed.v1`| If the check validation for a ScaledJob fails | `keda.scaledjob.removed.v1`| When a ScaledJob is deleted | | `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created | | `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | | `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted | | `keda.authentication.clustertriggerauthentication.created.v1`| On the first time a ClusterTriggerAuthentication is created | | `keda.authentication.clustertriggerauthentication.updated.v1`| When a ClusterTriggerAuthentication is updated | | `keda.authentication.clustertriggerauthentication.removed.v1`| When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.16/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.16 | v1.29 - v1.31 | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | ---------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.16/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (external metrics only): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.16/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory. Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`. ================================================ FILE: content/docs/2.16/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.16/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | | ================================================ FILE: content/docs/2.16/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_15" >}} ================================================ FILE: content/docs/2.16/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## gRPC Remote Procedure Calls (gRPC) gRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.16/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). **eager** When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible. For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours. ### pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: rabbitmq metadata: queueName: woker_queue hostFromEnv: RABBITMQ_URL mode: QueueLength value: "1" ``` We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 3 | If we switch to `eager`, the result becomes: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 6 | We can identify the difference in their final states. You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.16/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. When scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N. If you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ### scalingModifiers If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.16/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.16/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.16/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.16/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.16/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Datastore" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.16/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.16/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Optional: ignoreNullValues ignoreNullValues: "false" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response. If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional) > Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload. - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.16/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.16/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.16/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.16/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.16/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.16/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.16/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) > When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.16/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides ### Links - [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) - [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity) - [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity) ================================================ FILE: content/docs/2.16/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "0.5" activationTargetValue: "3.5" activeDirectoryClientId: # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.16/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not use demands in your agent scaler then it scales based on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.16/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.16/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.16/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' queueLengthStrategy: all|visibleonly activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 # Optional queueLengthStrategy: "all" # or visibleonly. Default: all cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.16/scalers/beanstalkd.md ================================================ +++ title = "Beanstalkd" availability = "v2.16+" maintainer = "Community" description = "Scale applications based on beanstalkd queues" go_file = "beanstalkd_scaler" +++ ### Trigger Specification This specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue. ```yaml triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 includeDelayed: "false" tube: "default" activationValue: "10" value: "15" timeout: "30" ``` **Parameter list:** - `server` - Address of beanstalkd server `:`. If no port is specified then the scaler will default to `11300`. - `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted. - `tube` - Name of the tube to scale on. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set. - `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional) ### Authentication Parameters No authentication should be needed to connect to the beanstalkd server. ### Example #### Default tube with activation value Here the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'default' activationValue: "10" value: "20" ``` #### User-created tube with minimum replicas A minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'scaling-tube' value: "5" includeDelayed: "true" ``` ================================================ FILE: content/docs/2.16/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. - `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional). - `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional) - `key` - Key path for client authentication. Mandatory if tls enabled. (Optional) ### Example with no TLS auth ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ### Example with TLS auth Since we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes: - name: temp-cassandra-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes.keda.extraVolumes - name: temp-cassandra-vol emptyDir: medium: Memory ``` Once we have the writable mount path set up for the certificates and keys. ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD tls: enable cert: key: ## Optional parameter ca ## ca: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password - parameter: tls name: cassandra-secrets key: tls - parameter: cert name: cassandra-secrets key: cert - parameter: key name: cassandra-secrets key: key ## Optional parameter ca ## - parameter: ca name: cassandra-secrets key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.16/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.16/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.16/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.16/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). There are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately. ## Using the Datadog Cluster Agent (Experimental) With this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches. ### Deploy the Datadog Cluster Agent with enabled external metrics First, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA). If you are using Helm to deploy the Cluster Agent, set: * `clusterAgent.metricsProvider.enabled` to `true` * `clusterAgent.metricsProvider.registerAPIService` to `false` * `clusterAgent.metricsProvider.useDatadogMetrics` to `true` * `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}]` If you are using the Datadog Operator, add the following options to your `DatadogAgent` object: ``` apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: name: datadog spec: features: externalMetricsServer: enabled: true useDatadogMetrics: true registerAPIService: false override: clusterAgent: env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}] [...] ``` NOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later. ### Create a DatadogMetric object for each scaling query To use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: "true"` annotation, to ensure the Cluster Agent retrieves the query value. Example: ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: annotations: external-metrics.datadoghq.com/always-active: "true" name: nginx-hits spec: query: sum:nginx.net.request_per_s{kube_deployment:nginx} ``` ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType metricUnavailableValue: "1.5" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional) - `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events. - `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events. - `targetValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication The Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Common to all authentication types** - `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional) - `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed. - `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern. - `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional) **Bearer authentication:** - `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-config namespace: my-project type: Opaque data: datadogNamespace: # Required: base64 encoded value of the namespace where the Datadog Cluster Agent is deployed datadogMetricsService: # Required: base64 encoded value of the Cluster Agent metrics server service unsafeSsl: # Optional: base64 encoded value of `true` or `false` authMode: # Required: base64 encoded value of the authentication mode (in this case, bearer) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: datadog-cluster-agent-creds namespace: my-project spec: secretTargetRef: - parameter: token name: dd-cluster-agent-token key: token - parameter: datadogNamespace name: datadog-config key: datadogNamespace - parameter: unsafeSsl name: datadog-config key: unsafeSsl - parameter: authMode name: datadog-config key: authMode - parameter: datadogMetricsService name: datadog-config key: datadogMetricsService --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx maxReplicaCount: 3 minReplicaCount: 1 pollingInterval: 60 triggers: - type: datadog metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "2" type: "global" authenticationRef: name: datadog-cluster-agent-creds ``` ## Using the Datadog REST API ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "false" query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false) - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ### Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../reference/scaledobject-spec/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ### Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. #### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. #### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ### Cases of unexpected metrics value in DataDog API response #### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue #### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.16/scalers/dynatrace.md ================================================ +++ title = "Dynatrace" availability = "2.15+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Dynatrace metric data points" go_file = "dynatrace_scaler" +++ ### Trigger Specification This specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points. ```yaml triggers: - type: dynatrace metadata: host: https://dummy-instance.live.dynatrace.com/ metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' # Optional from: now-2d threshold: "10" # Optional activationThreshold: "5" ``` **Parameter list:** - `host` - The Dynatrace instance to query against - `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). Some relevant aspects: - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector - `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters. **Authentication:** - `host` - The Dynatrace instance to query against - `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/ token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' from: 'now-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ================================================ FILE: content/docs/2.16/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html). The trigger always requires the following information, but requires either only searchTemplateName **or** only query: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" query: "my-query" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `query` - The query to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Examples Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" query: | { "size": 0, "query": { "bool": { "must": [ { "term": { "service.name": "my-application" } }, { "term": { "service.environment": "production" } }, { "range": { "@timestamp": { "gte": "now-2m", "lte": "now-1m" } } } ] } }, "aggs": { "transaction_count": { "cardinality": { "field": "transaction.id" } } } } valueLocation: "aggregations.transaction_count.value" targetValue: "1000" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.16/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' usernameFromEnv: # Optional passwordFromEnv: # Optional ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Password based authentication:** - `username` - Username for authentication. (Optional) - `password` - Password for authentication. (Optional) **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on Password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: etcd-username: etcd-password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-etcd-secrets key: etcd-username - parameter: password name: keda-etcd-secrets key: etcd-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.16/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.16/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.16/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 filterDuration: '1' # Optional - Default is 2 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.16/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 valueIfNull: '0.0' # Optional - Default is "" activationValue: "10.5" # Optional - Default is 0 timeHorizon: "1m" # Optional - Default is 2m and with aggregation 5m # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`) - `valueIfNull` - Value returned if request returns no timeseries.(Default: `""`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.16/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" filterDuration: '1' # Optional - Default is 2 activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.16/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.16/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false", defaults to "false" (scale on default runner labels) noDefaultLabels: "{noDefaultLabels}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabels` - Not scale on default runner labels ("self-hosted", "linux", "x64"). (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabelsFromEnv` - Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false". (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.16/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.16/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.16/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name tlsDisabled: # DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18 queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret unsafeSsl: "false" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ). - `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional) - `tlsDisabled` - Can be set to 'true' to disable TLS. (DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18, Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example Example with Basic Auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` Example with Basic Auth and TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password cert: key: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD - parameter: cert name: keda-ibmmq-secret key: cert - parameter: key name: keda-ibmmq-secret key: key ``` ================================================ FILE: content/docs/2.16/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.16/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.16/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.16/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.16/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.16/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.16/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.16/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.16/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.16/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.16/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. **TLS Authentication** - `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### Example without any TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with no TLS ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` #### Example with TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-stan-secrets namespace: default data: tls: enable ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: default spec: secretTargetRef: - parameter: tls name: keda-stan-secrets key: tls - parameter: ca name: keda-stan-secrets key: ca - parameter: cert name: keda-stan-secrets key: cert - parameter: key name: keda-stan-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "true" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.16/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.16/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.16/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.16/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for three connection options: A user can offer a full connection string (often in the form of an environment variable secret). - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. It is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity. More details and an example are provided down below. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` **Azure Access Token authentication:** #### Prerequisites: - The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity). - The UAMI should be granted access to the table mentioned in the query performed by KEDA. This can be achieved by: - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role. - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like `GRANT ALL ON TO "";`. Next, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process. - `host` - FQDN of the Azure Postgres Flexible Server. - `userName` - Name of the UAMI Azure identity (``). - `port` - Postgresql port (the default value is `"5432"`, please have a look at the `Remarks` down below). - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database (the value should be `require`). #### Remarks - While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-pg-flex-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql authenticationRef: name: azure-pg-flex-auth metadata: host: port: "5432" userName: dbName: sslmode: require query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.16/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.16/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.16/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.16/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of TriggerAuthentication passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of TriggerAuthentication unsafeSsl: true ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username to use to connect to the broker's management endpoint. - `passwordFromEnv` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. **Username and Password based authentication:** This allows sensitive credentials to be stored and managed separately from the connection string. - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** If username or password are set in TriggerAuthentication or environment variables, they will override any credentials provided in the host. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQP protocol with user/password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://localhost:5672/vhost (no username/password) username: # base64 encoded value of username password: # base64 encoded value of password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: username name: keda-rabbitmq-secret key: username - parameter: password name: keda-rabbitmq-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.16/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.16/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.16/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.16/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.16/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "myprimary" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.16/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.16/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars, SeleniumHQ" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration with default values represent. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: '' # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`). browserVersion: '' # Optional. platformName: '' # Optional. unsafeSsl : 'false' # Optional. activationThreshold: 0 # Optional. ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional). **Trigger Authentication** - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional) - `accessToken` - Access token. This is required when `authType` is set a value. (Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' unsafeSsl : 'true' ``` Noted: - From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details. The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` With above script, the request is sent to Grid. Via GraphQL response, it looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 0, "totalSlots": 0 }, "nodesInfo": { "nodes": [] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` In Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which is set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata. When the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 1, "totalSlots": 1 }, "nodesInfo": { "nodes": [ { "id": "UUID-of-Node", "status": "UP", "sessionCount": 0, "maxSession": 1, "slotCount": 1, "stereotypes": "[{\"slots\": 1, \"stereotype\": {\"browserName\": \"chrome\", \"browserVersion\": \"\", \"platformName\": \"Linux\"}}]", "sessions": [] } ] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` Now, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in. Moreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome-131 labels: deploymentName: selenium-node-chrome-131 spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:131.0 ports: - containerPort: 5555 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-131 namespace: keda labels: deploymentName: selenium-node-chrome-131 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-131 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '131.0' unsafeSsl : 'true' ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '131.0') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` Similarly, for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-firefox namespace: keda labels: deploymentName: selenium-node-firefox spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-firefox triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' platformName: 'Linux' unsafeSsl : 'true' ``` Request to trigger the scaler ```python options = FirefoxOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` Similarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-edge namespace: keda labels: deploymentName: selenium-node-edge spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-edge triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' platformName: 'Linux' unsafeSsl : 'true' ``` Request to trigger the scaler ```python options = EdgeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` In case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' nodeMaxSessions: 4 unsafeSsl : 'true' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '91.0' unsafeSsl : 'true' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '90.0' unsafeSsl : 'true' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL graphql-username: base64 encoded value of GraphQL Username graphql-password: base64 encoded value of GraphQL Password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url - parameter: username name: selenium-grid-secret key: graphql-username - parameter: password name: selenium-grid-secret key: graphql-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: browserName: 'chrome' platformName: 'Linux' unsafeSsl : 'true' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.16/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.16/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.16/scalers/splunk.md ================================================ +++ title = "Splunk" availability = "v2.15+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk saved search results." go_file = "splunk_scaler" +++ ### Trigger Specification This specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches). The trigger always requires the following information: ```yaml triggers: - type: splunk metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "1" activationValue: "10" savedSearchName: my-saved-search-name valueField: count ``` **Parameter list:** - `host` - Search API host and port. Example: `https://localhost:8089`. - `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `"true"`, `"false"`, Default: `"false"`, Optional) - `targetValue` - Value to reach to start scaling (This value can be a integer or float). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `savedSearchName` - Name of saved search that returns metric data for scaling. - `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`. ### Authentication Parameters You can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication. > **Note:** > > `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API. **Parameter list:** - `username` - Splunk username authorized to access the search API. - `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`. - `password` - Password for supplied `username`. Conflicts with `apiToken`. The user will need access to the saved search. ### Examples ### Username/password ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### API Token ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # admin apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: apiToken name: splunk-creds key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### Full example using Splunk deployment ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: splunkconf data: default.yml: | splunk: conf: - key: savedsearches value: directory: /opt/splunk/etc/users/admin/search/local content: my-saved-search-name: action.email.useNSSubject: 1 action.webhook.enable_allowlist: 0 alert.track: 0 cron_schedule: '*/1 * * * *' dispatch.earliest_time: -15m dispatch.latest_time: now display.general.type: statistics display.page.search.tab: statistics display.visualizations.show: 0 enableSched: 1 request.ui_dispatch_app: search request.ui_dispatch_view: search search: index=_internal | tail | stats count --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: v1 kind: Service metadata: name: splunk spec: ports: - port: 8000 targetPort: web name: web-svc - port: 8089 targetPort: 8089 name: api-svc selector: app: splunk --- apiVersion: apps/v1 kind: Deployment metadata: name: splunk namespace: default spec: replicas: 1 selector: matchLabels: app: splunk template: metadata: labels: app: splunk spec: containers: - name: splunk image: splunk/splunk:9.2 ports: - containerPort: 8000 name: web - containerPort: 8089 name: api env: - name: SPLUNK_START_ARGS value: --accept-license - name: SPLUNK_PASSWORD value: password volumeMounts: - name: splunkconf-volume mountPath: /tmp/defaults volumes: - name: splunkconf-volume configMap: name: splunkconf --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8080 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 unsafeSsl: "true" targetValue: "5" activationValue: "5" savedSearchName: my-saved-search-name valueField: count ``` ================================================ FILE: content/docs/2.16/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.16/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.17/_index.md ================================================ +++ title = "Getting Started" description = "How you can start with KEDA as new user" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation bar on the left to learn more about KEDA's architecture and how to deploy and use KEDA. ## Where to go What is your involvement with KEDA? | Role | Documentation | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | User | This documentation is for users who want to deploy KEDA to scale Kubernetes. | | Core Contributor | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda). | | Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). | | Other Contributor | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers. | ================================================ FILE: content/docs/2.17/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.17/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.17/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optionqal ``` ================================================ FILE: content/docs/2.17/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. **Regional STS endpoints** - If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace. - If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses). ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: namespace: annotations: eks.amazonaws.com/role-arn: # Required for regional STS endpoints (e.g. eu-west-1) eks.amazonaws.com/sts-regional-endpoints: "true" ``` ### When do you need regional STS endpoints? By default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`). Some regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`). If you see errors like: ``` AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity ``` while your IAM trust policy looks correct, you likely need to enable regional endpoints with: ```yaml annotations: eks.amazonaws.com/sts-regional-endpoints: "true" ``` 👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure Attach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.17/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.17/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.17/authentication-providers/bound-service-account-token.md ================================================ +++ title = "Bound service account token" +++ You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ## Permissions for KEDA to request service account tokens By default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster. To allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource. Here's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator namespace: my-namespace # Replace with the namespace of the service account rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - my-service-account # Replace with the name of the service account --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding namespace: my-namespace # Replace with the namespace of the service account roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator subjects: - kind: ServiceAccount name: keda-operator namespace: keda # Assuming the keda-operator service account is in the keda namespace ``` After applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API. ### Usage in keda-charts If you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example: ```yaml # values.yaml permissions: operator: restrict: serviceAccountTokenCreationRoles: - name: myServiceAccount namespace: myServiceAccountNamespace ``` This will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator-myServiceAccount namespace: myServiceAccountNamespace rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - myServiceAccount --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding-myServiceAccount namespace: myServiceAccountNamespace roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator-myServiceAccount subjects: - kind: ServiceAccount name: keda-operator namespace: keda ``` ================================================ FILE: content/docs/2.17/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.17/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.17/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.17/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.17/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.17/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.17/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests. It’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup. ## How KEDA works KEDA monitors external event sources and adjusts your app’s resources based on the demand. Its main components work together to make this possible: * **KEDA Operator** keeps track of event sources and changes the number of app instances up or down, depending on the demand. * **Metrics Server** provides external metrics to Kubernetes’ HPA so it can make scaling decisions. * **Scalers** connect to event sources like message queues or databases, pulling data on current usage or load. * **Custom Resource Definitions (CRDs)** define how your apps should scale based on triggers like queue length or API request rates. In simple terms, KEDA listens to what’s happening outside Kubernetes, fetches the data it needs, and scales your apps accordingly. It’s efficient and integrates well with Kubernetes to handle scaling dynamically. ## KEDA Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) External events, like an increase in queue messages, trigger the **ScaledObject**, which sets the scaling rules. The **Controller** handles the scaling, while the **Metrics Adapter** sends data to the HPA for real-time scaling decisions. **Admission Webhooks** ensure your configuration is correct and won’t cause problems. This setup lets Kubernetes adjust resources automatically based on what’s happening outside, keeping things efficient and responsive. ## KEDA Custom Resources (CRDs) KEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior: * **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works. * **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics. * **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials. These CRDs give you control over scaling while keeping your apps secure and responsive to demand. ## Scaling Deployments, StatefulSets, and Custom Resources KEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs. ### Scaling Deployments and StatefulSets With KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand. Deployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand. ### Scaling Custom Resources KEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically. ### Scaling Jobs KEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed. ### Authentication KEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe. ### External Scalers KEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly. ### Admission Webhooks KEDA uses admission webhooks to validate your scaling setup. They ensure your configuration is correct, like preventing multiple ScaledObjects from targeting the same app. This reduces errors and makes scaling smoother. ================================================ FILE: content/docs/2.17/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.17/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Bound service account token(s) You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.17/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.17/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ This page describes the deployment scaling behavior of KEDA. # Specification See the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below. # Scaling objects ## Scaling Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## Scaling Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). # Features ## Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval. Enabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ## Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`. ## Scaling Modifiers **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ## Activating and Scaling thresholds KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Transferring ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disabling validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ### Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. #### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. #### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](./scaling-jobs). ================================================ FILE: content/docs/2.17/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ This page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below. # Overview As an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` # Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` To reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`. ```yaml metadata: annotations: autoscaling.keda.sh/paused: false ``` ## Example An example configuration for autoscaling jobs using a RabbitMQ scaler is given below. ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.17/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.17/deploy.md ================================================ +++ title = "Deploying KEDA" +++ KEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization. Using **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster. Each method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment. > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.29 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Prerequisites To deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features. If you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease. ### Installing 1. To deploy KEDA using Helm, first add the official KEDA Helm repository: ```sh helm repo add kedacore https://kedacore.github.io/charts helm repo update ``` 2. Install `keda` by running: **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods: ```sh kubectl get pods -n keda ``` To deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps: 1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version. 2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions: ```sh kubectl apply -f keda-2.xx.x-crds.yaml ``` Replace `2.xx.x` with the specific version number you downloaded. By deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process. > 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues. Deploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments. ### Uninstalling To uninstall KEDA, use the following Helm command: ```sh helm uninstall keda –namespace keda ``` This command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run: ```sh kubectl delete namespace keda ``` Uninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version. You can remove finalizers with the following command: ```sh kubectl patch scaledobject -p '{"metadata":{"finalizers":null}}' --type=merge kubectl patch scaledjob -p '{"metadata":{"finalizers":null}}' --type=merge ``` Replace \<*resource-name*\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster. ## Deploying with Operator Hub {#operatorhub} ### Prerequisites Before deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access. If you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub. ### Installing To deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed. Search for "KEDA" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace. 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) Using Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment. > 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository: > > [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator) > > This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments. > > For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful: > > \- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator. > > \- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster. > > \- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project. ### Uninstalling To uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster. If you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks. ## Deploying KEDA using the YAML files {#yaml} ### Prerequisites Before deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster. ### Installing Once the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command: ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3-core.yaml ``` Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.17.3.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.17.3-core.yaml ``` The `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740). > 💡 **NOTE:** If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally: > > ```sh > git clone https://github.com/kedacore/keda && cd keda > > VERSION=2.17.3 make deploy > ``` > > This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization. After applying the YAML, verify the deployment by checking the KEDA namespace: ```sh kubectl get pods -n keda ``` Deploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates. ### Uninstalling If you installed KEDA using the released YAML files, you can uninstall it by running the following commands: ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3-core.yaml ``` If you downloaded the files locally, uninstall with: ```sh # Including admission webhooks kubectl delete -f keda-2.17.3.yaml # Without admission webhooks kubectl delete -f keda-2.17.3-core.yaml ``` For users who cloned the KEDA GitHub repository, navigate to the cloned directory and use: ```sh VERSION=2.17.3 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Prerequisites Before deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`). Additionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons: * **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration. * **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation. ### Installing To install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on. 1. Enable Helm and DNS Add-ons (if not already enabled): ```sh microk8s enable dns helm3use ``` 2. Add the KEDA Helm Repository: ```sh microk8s helm3 repo add kedacore https://kedacore.github.io/charts microk8s helm3 repo update ``` 3. Install KEDA Using Helm. Deploy KEDA into your MicroK8s cluster by running: ```sh microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace ``` 4. Verify the Installation. Check that KEDA is running by listing the pods in the keda namespace: ```sh microk8s kubectl get pods -n keda ``` This approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development. ### Uninstalling To uninstall KEDA from your MicroK8s environment, disable the KEDA add-on: ```sh microk8s disable keda ``` This command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation. If you deployed KEDA using Helm, uninstall it with: ```sh microk8s helm3 uninstall keda --namespace keda ``` After running these commands, KEDA will be fully removed from your MicroK8s setup. ## Getting Started with KEDA: A Simple Example To help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This "Hello KEDA" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality. Before starting, ensure you have the following: * **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service. * **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster. * **KEDA Installed**: KEDA should be installed in your cluster. ### Step 1: Deploy a Sample Application We'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server. 1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: http-app spec: replicas: 1 selector: matchLabels: app: http-app template: metadata: labels: app: http-app spec: containers: - name: http-app image: hashicorp/http-echo args: - "-text=Hello, KEDA!" ports: - containerPort: 5678 ``` 2. **Apply the Deployment**: Run the following command to create the deployment: ```sh kubectl apply -f deployment.yaml ``` ### Step 2: Expose the Application To access the application, we'll create a Service. 1. **Create a Service Manifest**: Save the following YAML as service.yaml: ```yaml apiVersion: v1 kind: Service metadata: name: http-app-service spec: selector: app: http-app ports: - protocol: TCP port: 80 targetPort: 5678 type: LoadBalancer ``` 2. **Apply the Service**: Run the following command to create the service: ```sh kubectl apply -f service.yaml ``` 3. **Retrieve the External IP**: After a few moments, retrieve the external IP address: ```sh kubectl get service http-app-service ``` ### Step 3: Create a ScaledObject We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. 1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-app-scaledobject spec: scaleTargetRef: name: http-app minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: prometheus metadata: serverAddress: http://prometheus-server.default.svc.cluster.local:9090 threshold: '5' query: sum(rate(http_requests_total[1m])) ``` > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed. 2. **Apply the ScaledObject**: Run the following command to create the ScaledObject: ```sh kubectl apply -f scaledobject.yaml ``` ### Step 4: Test the Scaling Behavior We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. To observe KEDA's scaling in action: 1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP: ```sh hey -z 1m -c 10 http:// ``` Replace `` with the external IP address obtained earlier. 2. **Monitor Scaling:** Run the following command to watch the scaling behavior: ```sh kubectl get pods -w ``` You should see the number of pods increase as the load increases and decrease when the load subsides. ### Cleanup After completing the exercise, clean up the resources: ```sh kubectl delete -f scaledobject.yaml kubectl delete -f service.yaml kubectl delete -f deployment.yaml ``` This example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events. ================================================ FILE: content/docs/2.17/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.17/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.17/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.17/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). > Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.17/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.17/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance and requirements for operating KEDA" weight = 1 +++ We provide guidance and requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](../reference/events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.17/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ### Cache Miss with Fallback to Direct Client for ScaledObject When validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`: ``` --cache-miss-to-direct-client=true ``` This will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API. ## Custom Validations using Kubernetes ValidatingAdmissionPolicy > ⚠️ FEATURE STATE: Kubernetes v1.30 [stable] Kubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). Here is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10): ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-keda-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["keda.sh"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["scaledobjects"] validations: - expression: "object.spec.maxReplicaCount <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-keda-replicas-binding.example.com" spec: policyName: "limit-keda-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` Since KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas: ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-apps-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments", "replicasets"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-hpa-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["autoscaling"] apiVersions: ["v2"] operations: ["CREATE", "UPDATE"] resources: ["horizontalpodautoscalers"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-apps-replicas-binding.example.com" spec: policyName: "limit-apps-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-hpa-replicas-binding.example.com" spec: policyName: "limit-hpa-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` ================================================ FILE: content/docs/2.17/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | | `keda.scaledobject.removed.v1`| When a ScaledObject is deleted | | `keda.scaledjob.ready.v1`| On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledjob.failed.v1`| If the check validation for a ScaledJob fails | `keda.scaledjob.removed.v1`| When a ScaledJob is deleted | | `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created | | `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | | `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted | | `keda.authentication.clustertriggerauthentication.created.v1`| On the first time a ClusterTriggerAuthentication is created | | `keda.authentication.clustertriggerauthentication.updated.v1`| When a ClusterTriggerAuthentication is updated | | `keda.authentication.clustertriggerauthentication.removed.v1`| When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.17/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.17 | v1.30 - v1.32 | | v2.16 | v1.29 - v1.31 | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 on the KEDA operator deployment to your desired timeout in milliseconds. > ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata. ## 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.17/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (external metrics only): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.17/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). Additionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources. Example use case: - When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources. 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory. Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`. ================================================ FILE: content/docs/2.17/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.17/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | | ================================================ FILE: content/docs/2.17/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_15" >}} ================================================ FILE: content/docs/2.17/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## gRPC Remote Procedure Calls (gRPC) gRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.17/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). **eager** When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible. For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours. ### pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: rabbitmq metadata: queueName: woker_queue hostFromEnv: RABBITMQ_URL mode: QueueLength value: "1" ``` We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 3 | If we switch to `eager`, the result becomes: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 6 | We can identify the difference in their final states. You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.17/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: {kind-of-behavior} # Optional. Default: "static" advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. When scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N. If you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: "static" # Optional. Default: "static" ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. ## fallback.behavior The `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used. #### `static` behavior When `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'. #### `currentReplicas` behavior When using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'. #### `currentReplicasIfHigher` behavior When using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'. #### `currentReplicasIfLower` behavior When using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` ### scalingModifiers If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional) #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.17/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.17/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.17/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.17/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.17/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Datastore" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.17/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.17/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Optional: ignoreNullValues ignoreNullValues: "false" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response. If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional) > Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload. - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.17/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.17/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.17/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.17/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.17/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.17/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.17/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) > When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.17/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" # Optional. Custom timeout for the HTTP client used in this scaler timeout: "1000" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides ### Links - [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) - [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity) - [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity) ================================================ FILE: content/docs/2.17/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "0.5" activationTargetValue: "3.5" activeDirectoryClientId: # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.17/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: Require jobs to include specified demands, ignoring any extra ones requireAllDemandsAndIgnoreOthers: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not use demands in your agent scaler then it scales based on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list. - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.17/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.17/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.17/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' queueLengthStrategy: all|visibleonly activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 # Optional queueLengthStrategy: "all" # or visibleonly. Default: all cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.17/scalers/beanstalkd.md ================================================ +++ title = "Beanstalkd" availability = "v2.16+" maintainer = "Community" description = "Scale applications based on beanstalkd queues" go_file = "beanstalkd_scaler" +++ ### Trigger Specification This specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue. ```yaml triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 includeDelayed: "false" tube: "default" activationValue: "10" value: "15" timeout: "30" ``` **Parameter list:** - `server` - Address of beanstalkd server `:`. If no port is specified then the scaler will default to `11300`. - `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted. - `tube` - Name of the tube to scale on. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set. - `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional) ### Authentication Parameters No authentication should be needed to connect to the beanstalkd server. ### Example #### Default tube with activation value Here the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'default' activationValue: "10" value: "20" ``` #### User-created tube with minimum replicas A minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'scaling-tube' value: "5" includeDelayed: "true" ``` ================================================ FILE: content/docs/2.17/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. - `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional). - `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional) - `key` - Key path for client authentication. Mandatory if tls enabled. (Optional) ### Example with no TLS auth ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ### Example with TLS auth Since we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes: - name: temp-cassandra-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes.keda.extraVolumes - name: temp-cassandra-vol emptyDir: medium: Memory ``` Once we have the writable mount path set up for the certificates and keys. ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD tls: enable cert: key: ## Optional parameter ca ## ca: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password - parameter: tls name: cassandra-secrets key: tls - parameter: cert name: cassandra-secrets key: cert - parameter: key name: cassandra-secrets key: key ## Optional parameter ca ## - parameter: ca name: cassandra-secrets key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.17/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.17/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.17/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be the same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale your deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do it the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.17/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). There are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately. ## Using the Datadog Cluster Agent (Experimental) With this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches. ### Deploy the Datadog Cluster Agent with enabled external metrics First, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA). If you are using Helm to deploy the Cluster Agent, set: * `clusterAgent.metricsProvider.enabled` to `true` * `clusterAgent.metricsProvider.registerAPIService` to `false` * `clusterAgent.metricsProvider.useDatadogMetrics` to `true` * `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}]` If you are using the Datadog Operator, add the following options to your `DatadogAgent` object: ``` apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: name: datadog spec: features: externalMetricsServer: enabled: true useDatadogMetrics: true registerAPIService: false override: clusterAgent: env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}] [...] ``` NOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later. ### Create a DatadogMetric object for each scaling query To use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: "true"` annotation, to ensure the Cluster Agent retrieves the query value. Example: ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: annotations: external-metrics.datadoghq.com/always-active: "true" name: nginx-hits spec: query: sum:nginx.net.request_per_s{kube_deployment:nginx} ``` ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType metricUnavailableValue: "1.5" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional) - `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events. - `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events. - `targetValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication The Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below: **Common to all authentication types** - `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional) - `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed. - `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern. - `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional) **Bearer authentication:** - `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated. ### Example ```yaml apiVersion: v1 kind: ConfigMap metadata: name: datadog-config namespace: my-project data: datadogNamespace: # Required: namespace where the Datadog Cluster Agent is deployed datadogMetricsService: # Required: Cluster Agent metrics server service name unsafeSsl: # Optional: set to "true" to skip SSL certificate validation authMode: # Required: authentication mode (bearer) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: datadog-cluster-agent-creds namespace: my-project spec: boundServiceAccountToken: - parameter: token serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io configMapTargetRef: - parameter: datadogNamespace name: datadog-config key: datadogNamespace - parameter: unsafeSsl name: datadog-config key: unsafeSsl - parameter: authMode name: datadog-config key: authMode - parameter: datadogMetricsService name: datadog-config key: datadogMetricsService --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx maxReplicaCount: 3 minReplicaCount: 1 pollingInterval: 60 triggers: - type: datadog metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "2" type: "global" authenticationRef: name: datadog-cluster-agent-creds ``` ## Using the Datadog REST API ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "false" query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false) - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ### Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../reference/scaledobject-spec/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ### Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. #### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. #### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ### Cases of unexpected metrics value in DataDog API response #### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue #### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.17/scalers/dynatrace.md ================================================ +++ title = "Dynatrace" availability = "2.15+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Dynatrace metric data points" go_file = "dynatrace_scaler" +++ ### Trigger Specification This specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points. ```yaml triggers: - type: dynatrace metadata: host: https://dummy-instance.live.dynatrace.com/ metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' # Optional from: now-2d threshold: "10" # Optional activationThreshold: "5" ``` **Parameter list:** - `host` - The Dynatrace instance to query against - `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). Some relevant aspects: - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector - `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters. **Authentication:** - `host` - The Dynatrace instance to query against - `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/ token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' from: 'now-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ================================================ FILE: content/docs/2.17/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html). The trigger always requires the following information, but requires either only searchTemplateName **or** only query: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" query: "my-query" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `query` - The query to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Examples Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" query: | { "size": 0, "query": { "bool": { "must": [ { "term": { "service.name": "my-application" } }, { "term": { "service.environment": "production" } }, { "range": { "@timestamp": { "gte": "now-2m", "lte": "now-1m" } } } ] } }, "aggs": { "transaction_count": { "cardinality": { "field": "transaction.id" } } } } valueLocation: "aggregations.transaction_count.value" targetValue: "1000" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.17/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' usernameFromEnv: # Optional passwordFromEnv: # Optional ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Password based authentication:** - `username` - Username for authentication. (Optional) - `password` - Password for authentication. (Optional) **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on Password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: etcd-username: etcd-password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-etcd-secrets key: etcd-username - parameter: password name: keda-etcd-secrets key: etcd-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.17/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.17/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem enableTLS: false unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.17/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 filterDuration: '1' # Optional - Default is 2 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.17/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 valueIfNull: '0.0' # Optional - Default is "" activationValue: "10.5" # Optional - Default is 0 timeHorizon: "1m" # Optional - Default is 2m and with aggregation 5m # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`) - `valueIfNull` - Value returned if request returns no timeseries.(Default: `""`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.17/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" filterDuration: '1' # Optional - Default is 2 activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.17/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.17/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false", defaults to "false" (scale on default runner labels) noDefaultLabels: "{noDefaultLabels}" # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either "true" or "false", defaults to "false" enableEtags: "{enableEtags}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabels` - Not scale on default runner labels ("self-hosted", "linux", "x64"). (Values: `true`,`false`, Default: "false", Optional) - `enableEtags` - Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabelsFromEnv` - Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false". (Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations: - Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories. - Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **Fine-Tuning** The current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters. For example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly. *Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).* At the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.17/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.17/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.17/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name tlsDisabled: # DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18 queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret unsafeSsl: "false" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ). - `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional) - `tlsDisabled` - Can be set to 'true' to disable TLS. (DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18, Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example Example with Basic Auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` Example with Basic Auth and TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password cert: key: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD - parameter: cert name: keda-ibmmq-secret key: cert - parameter: key name: keda-ibmmq-secret key: key ``` ================================================ FILE: content/docs/2.17/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.17/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.17/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.17/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.17/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.17/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below. Multiple authentication methods can be used simultaneously by providing a comma-separated list in the `authMode` parameter, for example `authMode: "apiKey,tls"` enables both API key and TLS certificate authentication in a single request. **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.17/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. This value can be a float. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.17/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.17/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.17/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.17/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ > **Notice:** > The Stan scaler (NATS Streaming) is DEPRECATED and will be removed in v2.19 - Use scaler [nats-jetstream](./nats-jetstream.md) instead. > See also the deprecation notice [here](https://nats-io.gitbook.io/legacy-nats-docs/nats-streaming-server-aka-stan). ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. **TLS Authentication** - `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### Example without any TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with no TLS ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` #### Example with TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-stan-secrets namespace: default data: tls: enable ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: default spec: secretTargetRef: - parameter: tls name: keda-stan-secrets key: tls - parameter: ca name: keda-stan-secrets key: ca - parameter: cert name: keda-stan-secrets key: cert - parameter: key name: keda-stan-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "true" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.17/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example Autoscaling trigger based on transaction duration average metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` Autoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO" noDataError: "true" threshold: '300' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.17/scalers/nsq.md ================================================ +++ title = "NSQ" availability = "v2.17+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NSQ topic/channel depth." go_file = "nsq_scaler" +++ ### Trigger Specification This specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. ```yaml triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" useHttps: "false" unsafeSsl: "false" ``` **Parameter list:** - `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `:`. - `topic` - Name of the NSQ datastream that the `channel` relates to. - `channel` - Name of the channel used to calculate depth. - `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional) - `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional) - `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) > **Notice:** > - Since ["channels are created on first use by subscribing to the named channel"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0. > - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nsq-scaledobject spec: scaleTargetRef: name: nsq-consumer-deployment triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" ``` ================================================ FILE: content/docs/2.17/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.17/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.17/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for three connection options: A user can offer a full connection string (often in the form of an environment variable secret). - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. It is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity. More details and an example are provided down below. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` **Azure Access Token authentication:** #### Prerequisites: - The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity). - The UAMI should be granted access to the table mentioned in the query performed by KEDA. This can be achieved by: - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role. - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like `GRANT ALL ON TO "";`. Next, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process. - `host` - FQDN of the Azure Postgres Flexible Server. - `userName` - Name of the UAMI Azure identity (``). - `port` - Postgresql port (the default value is `"5432"`, please have a look at the `Remarks` down below). - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database (the value should be `require`). #### Remarks - While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-pg-flex-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql authenticationRef: name: azure-pg-flex-auth metadata: host: port: "5432" userName: dbName: sslmode: require query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.17/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.17/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint timeout: "1000" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.17/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.17/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow) # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of TriggerAuthentication passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of TriggerAuthentication unsafeSsl: true timeout: "1000" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` ) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username to use to connect to the broker's management endpoint. - `passwordFromEnv` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used) **Username and Password based authentication:** This allows sensitive credentials to be stored and managed separately from the connection string. - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** If username or password are set in TriggerAuthentication or environment variables, they will override any credentials provided in the host. **TLS authentication:** - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) > Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters. **Azure Workload Identity authentication:** For RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672 vhostName: vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: vhostName name: keda-rabbitmq-secret key: vhostName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQP protocol with user/password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://localhost:5672/vhost (no username/password) username: # base64 encoded value of username password: # base64 encoded value of password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: username name: keda-rabbitmq-secret key: username - parameter: password name: keda-rabbitmq-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.17/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.17/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.17/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.17/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.17/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "myprimary" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.17/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.17/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars, SeleniumHQ" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration with default values represent. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: '' # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`). browserVersion: '' # Optional. platformName: '' # Optional. unsafeSsl: false # Optional. activationThreshold: 0 # Optional. nodeMaxSessions: 1 # Optional. enableManagedDownloads: true # Optional. capabilities: '' # Optional. ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional). - `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional). - `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional) **Trigger Authentication** - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional) - `accessToken` - Access token. This is required when `authType` is set a value. (Optional) ### Example --- #### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion` Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' ``` Noted: - From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details. The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` With above script, the request is sent to Grid. Via GraphQL response, it looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 0, "totalSlots": 0 }, "nodesInfo": { "nodes": [] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` In Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata. When the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 1, "totalSlots": 1 }, "nodesInfo": { "nodes": [ { "id": "UUID-of-Node", "status": "UP", "sessionCount": 0, "maxSession": 1, "slotCount": 1, "stereotypes": "[{\"slots\": 1, \"stereotype\": {\"browserName\": \"chrome\", \"browserVersion\": \"\", \"platformName\": \"Linux\"}}]", "sessions": [] } ] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` Now, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in. --- #### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName` Moreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome-131 labels: deploymentName: selenium-node-chrome-131 spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:131.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '131.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-131 namespace: keda labels: deploymentName: selenium-node-chrome-131 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-131 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '131.0' unsafeSsl: 'true' ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '131.0') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` #### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads` In image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS value: "true" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Scaler trigger param configuration should be aligned with Node stereotype. enableManagedDownloads: "true" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid options.enable_downloads = True driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata with extra `capabilities` For an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options - name: SE_NODE_STEREOTYPE_EXTRA value: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536 capabilities: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes options.set_capability('myApp:version', 'beta') options.set_capability('myApp:publish', 'public') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Firefox browser ```yaml kind: Deployment metadata: name: selenium-node-firefox labels: deploymentName: selenium-node-firefox spec: replicas: 1 template: spec: containers: - name: selenium-node-firefox image: selenium/node-firefox:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-firefox namespace: keda labels: deploymentName: selenium-node-firefox spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-firefox triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = FirefoxOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Edge browser Similarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml kind: Deployment metadata: name: selenium-node-edge labels: deploymentName: selenium-node-edge spec: replicas: 1 template: spec: containers: - name: selenium-node-edge image: selenium/node-edge:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-edge namespace: keda labels: deploymentName: selenium-node-edge spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-edge triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = EdgeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions` In case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' - name: SE_NODE_OVERRIDE_MAX_SESSIONS value: 'true' - name: SE_NODE_MAX_SESSIONS value: '4' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' nodeMaxSessions: 4 unsafeSsl: 'true' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL graphql-username: base64 encoded value of GraphQL Username graphql-password: base64 encoded value of GraphQL Password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url - parameter: username name: selenium-grid-secret key: graphql-username - parameter: password name: selenium-grid-secret key: graphql-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.17/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.17/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.17/scalers/splunk.md ================================================ +++ title = "Splunk" availability = "v2.15+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk saved search results." go_file = "splunk_scaler" +++ ### Trigger Specification This specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches). The trigger always requires the following information: ```yaml triggers: - type: splunk metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "1" activationValue: "10" savedSearchName: my-saved-search-name valueField: count ``` **Parameter list:** - `host` - Search API host and port. Example: `https://localhost:8089`. - `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `"true"`, `"false"`, Default: `"false"`, Optional) - `targetValue` - Value to reach to start scaling (This value can be a integer or float). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `savedSearchName` - Name of saved search that returns metric data for scaling. - `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`. ### Authentication Parameters You can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication. > **Note:** > > `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API. **Parameter list:** - `username` - Splunk username authorized to access the search API. - `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`. - `password` - Password for supplied `username`. Conflicts with `apiToken`. The user will need access to the saved search. ### Examples ### Username/password ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### API Token ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # admin apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: apiToken name: splunk-creds key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### Full example using Splunk deployment ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: splunkconf data: default.yml: | splunk: conf: - key: savedsearches value: directory: /opt/splunk/etc/users/admin/search/local content: my-saved-search-name: action.email.useNSSubject: 1 action.webhook.enable_allowlist: 0 alert.track: 0 cron_schedule: '*/1 * * * *' dispatch.earliest_time: -15m dispatch.latest_time: now display.general.type: statistics display.page.search.tab: statistics display.visualizations.show: 0 enableSched: 1 request.ui_dispatch_app: search request.ui_dispatch_view: search search: index=_internal | tail | stats count --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: v1 kind: Service metadata: name: splunk spec: ports: - port: 8000 targetPort: web name: web-svc - port: 8089 targetPort: 8089 name: api-svc selector: app: splunk --- apiVersion: apps/v1 kind: Deployment metadata: name: splunk namespace: default spec: replicas: 1 selector: matchLabels: app: splunk template: metadata: labels: app: splunk spec: containers: - name: splunk image: splunk/splunk:9.2 ports: - containerPort: 8000 name: web - containerPort: 8089 name: api env: - name: SPLUNK_START_ARGS value: --accept-license - name: SPLUNK_PASSWORD value: password volumeMounts: - name: splunkconf-volume mountPath: /tmp/defaults volumes: - name: splunkconf-volume configMap: name: splunkconf --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8080 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 unsafeSsl: "true" targetValue: "5" activationValue: "5" savedSearchName: my-saved-search-name valueField: count ``` ================================================ FILE: content/docs/2.17/scalers/temporal.md ================================================ +++ title = "Temporal" availability = "v2.17+" maintainer = "Community" description = "Scale applications based on Temporal task queue." go_file = "temporal_scaler" +++ ### Trigger Specification This specification describes the `temporal` trigger that scales based on a Temporal task queue. ```yaml triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 queueTypes: workflow # optional buildId: 1.0.0 # optional selectAllActive: "false" # optional selectUnversioned: "false" # optional minConnectTimeout: "5" # optional unsafeSsl: "false" # optional ``` **Parameter list:** - `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `:`. (Required) - `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional) - `namespace` - The namespace of the temporal service. (Default:`default`, Optional) - `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional) - `taskQueue` - This parameter specifies the task queue name. (Required) - `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional) - `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional) - `selectAllActive` - Include all active versions (Default:`false`, Optional) - `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional) - `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional) - `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional) > 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero. This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog. Consequently, scaling to zero could result in undesirable behavior, such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA). By fine-tuning the configurations, you can prevent premature scaling to zero, ensuring that resources remain available for in-flight tasks or workloads with minimal throughput. **Authentication Parameters:** Temporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication: - `apiKey` - API key for authentication with temporal cloud. (Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: temporal-secret namespace: default type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-temporal namespace: default spec: secretTargetRef: - parameter: apiKey name: temporal-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject namespace: default spec: scaleTargetRef: name: workload-scaledobject pollingInterval: 5 cooldownPeriod: 10 minReplicaCount: 0 maxReplicaCount: 5 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 10 triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 authenticationRef: name: keda-trigger-auth-temporal ``` ================================================ FILE: content/docs/2.17/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.17/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.18/_index.md ================================================ +++ title = "Getting Started" description = "How you can start with KEDA as new user" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation bar on the left to learn more about KEDA's architecture and how to deploy and use KEDA. ## Where to go What is your involvement with KEDA? | Role | Documentation | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | User | This documentation is for users who want to deploy KEDA to scale Kubernetes. | | Core Contributor | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda). | | Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). | | Other Contributor | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers. | ================================================ FILE: content/docs/2.18/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.18/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.18/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optionqal ``` ================================================ FILE: content/docs/2.18/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. **Regional STS endpoints** - If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace. - If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses). ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: namespace: annotations: eks.amazonaws.com/role-arn: # Required for regional STS endpoints (e.g. eu-west-1) eks.amazonaws.com/sts-regional-endpoints: "true" ``` ### When do you need regional STS endpoints? By default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`). Some regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`). If you see errors like: ``` AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity ``` while your IAM trust policy looks correct, you likely need to enable regional endpoints with: ```yaml annotations: eks.amazonaws.com/sts-regional-endpoints: "true" ``` 👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure Attach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.18/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.18/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.18/authentication-providers/bound-service-account-token.md ================================================ +++ title = "Bound service account token" +++ You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ## Permissions for KEDA to request service account tokens By default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster. To allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource. Here's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator namespace: my-namespace # Replace with the namespace of the service account rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - my-service-account # Replace with the name of the service account --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding namespace: my-namespace # Replace with the namespace of the service account roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator subjects: - kind: ServiceAccount name: keda-operator namespace: keda # Assuming the keda-operator service account is in the keda namespace ``` After applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API. ### Usage in keda-charts If you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example: ```yaml # values.yaml permissions: operator: restrict: serviceAccountTokenCreationRoles: - name: myServiceAccount namespace: myServiceAccountNamespace ``` This will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator-myServiceAccount namespace: myServiceAccountNamespace rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - myServiceAccount --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding-myServiceAccount namespace: myServiceAccountNamespace roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator-myServiceAccount subjects: - kind: ServiceAccount name: keda-operator namespace: keda ``` ================================================ FILE: content/docs/2.18/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.18/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.18/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.18/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.18/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method. There's multiple methods for authentication; For kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) or provide the serviceAccountName that can authenticate to kubernetes in the namespace of the ScaledObject/ScaledJob resource (usually `default`). If using serviceAccountName make sure to grant KEDA Operator `create serviceaccounts/token` permissions. This is set in the helm chart via `permissions.operator.restrict.allowAllServiceAccountTokenCreation=true` For token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. Authenticate to vault via a supplied token serviceAccount: {path-to-service-account-file} # Optional. Authenticate to vault via JWT token in keda operator pod serviceAccountName: {service-account-name-for-auth} # Optional. Requires serviceaccounts/token create permissions. Authenticate to vault via JWT token from service account in ScaledObject/ScaledJob's namespace secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.18/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.18/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests. It’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup. ## How KEDA works KEDA monitors external event sources and adjusts your app’s resources based on the demand. Its main components work together to make this possible: * **KEDA Operator** keeps track of event sources and changes the number of app instances up or down, depending on the demand. * **Metrics Server** provides external metrics to Kubernetes’ HPA so it can make scaling decisions. * **Scalers** connect to event sources like message queues or databases, pulling data on current usage or load. * **Custom Resource Definitions (CRDs)** define how your apps should scale based on triggers like queue length or API request rates. In simple terms, KEDA listens to what’s happening outside Kubernetes, fetches the data it needs, and scales your apps accordingly. It’s efficient and integrates well with Kubernetes to handle scaling dynamically. ## KEDA Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) External events, like an increase in queue messages, trigger the **ScaledObject**, which sets the scaling rules. The **Controller** handles the scaling, while the **Metrics Adapter** sends data to the HPA for real-time scaling decisions. **Admission Webhooks** ensure your configuration is correct and won’t cause problems. This setup lets Kubernetes adjust resources automatically based on what’s happening outside, keeping things efficient and responsive. ## KEDA Custom Resources (CRDs) KEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior: * **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works. * **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics. * **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials. These CRDs give you control over scaling while keeping your apps secure and responsive to demand. ## Scaling Deployments, StatefulSets, and Custom Resources KEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs. ### Scaling Deployments and StatefulSets With KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand. Deployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand. ### Scaling Custom Resources KEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically. ### Scaling Jobs KEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed. ### Authentication KEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe. ### External Scalers KEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly. ### Consuming Raw Scaler Metrics Externally KEDA also allows consuming the internal metrics (coming from internal or external scalers) to interested 3rd parties. This feature is exposed using gRPC server stream API and needs to be first enabled by setting `RAW_METRICS_GRPC_PROTOCOL` to "`enabled`". Then one can subscribe to a metric identified by ScaledObject/ScaledJob name, namespace and trigger name using any gRPC client (example with [grpcurl](https://github.com/kedacore/keda/pull/7093#issuecomment-3333530716)). You can control when raw metrics are sent using the `RAW_METRICS_MODE` environment variable: * `all` or `""` (empty): Sends all raw metrics, both when the metrics server requests them (HPA) and during the regular polling interval of each ScaledObject or ScaledJob. This is the default behavior. * `hpa`: Sends raw metrics only when the Kubernetes metrics server explicitly requests metrics for a ScaledObject. This means metrics are sent in response to HPA queries, not on a regular schedule. * `pollinginterval`: Sends raw metrics only during the polling interval of each ScaledObject or ScaledJob. In this mode, metrics are pushed out at each polling cycle, regardless of HPA requests. * Any unknown value will default to the `all` mode. ### Admission Webhooks KEDA uses admission webhooks to validate your scaling setup. They ensure your configuration is correct, like preventing multiple ScaledObjects from targeting the same app. This reduces errors and makes scaling smoother. ================================================ FILE: content/docs/2.18/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.18/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Bound service account token(s) You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.18/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.18/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ This page describes the deployment scaling behavior of KEDA. # Specification See the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below. # Scaling objects ## Scaling Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## Scaling Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). # Features ## Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval. Enabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ## Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`. Additionally, we provide the ability to temporarily pause scale in on a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/paused-scale-in: "true" ``` When the annotation is set, KEDA will update the generated HPA to disable scale in (via setting the HPA's Scale Down Select Policy to Disabled) and if the service has scale to zero configured, will block scale to zero. When the annotation is unset, the scale down behavior on the HPA will be restored to its original configuration and, if configured, scale to zero will be unblocked. Conversely, we provide the ability to temporarily pause scale out on a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/paused-scale-out: "true" ``` When the annotation is set, KEDA will update the generated HPA to disable scale out (via setting the HPA's Scale Up Select Policy to Disabled) and if the service has scale to zero configured, will block scale from zero. When the annotation is unset, the scale up behavior on the HPA will be restored to its original configuration and, if configured, scale up from zero will be unblocked. If you want disable scaling in both directions, we recommend you use the `autoscaling.keda.sh/paused` as that will stop the scale loop and paused queries against the ScaledObject's configured scaler. ## Scaling Modifiers **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ## Activating and Scaling thresholds KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Forcing Activation We provide the ability to temporarily force the activation of a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/force-activation: "true" ``` When the annotation is set, KEDA will treat all configured scalers as active. If the scalers were previously not active, KEDA will scale the service up from 0. When the annotation is subsequently unset, the state of the scaler activation will revert to being computed from the state of the scaler metrics. ## Transferring ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disabling validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ### Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. #### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. #### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](./scaling-jobs). ## Excluding labels from being propagated to the HPA You can exclude specific labels from being propagated to the generated HPA object by using the `scaledobject.keda.sh/hpa-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded. ```yaml metadata: annotations: scaledobject.keda.sh/hpa-excluded-labels: "foo.bar/environment,foo.bar/version" labels: team: backend foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5 foo.bar/version: "1" ================================================ FILE: content/docs/2.18/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ This page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below. # Overview As an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` # Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` To reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`. ```yaml metadata: annotations: autoscaling.keda.sh/paused: false ``` ## Example An example configuration for autoscaling jobs using a RabbitMQ scaler is given below. ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` # Excluding labels from being propagated to the Job You can exclude specific labels from being propagated to the generated Job object by using the `scaledjob.keda.sh/job-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded. ```yaml metadata: annotations: scaledjob.keda.sh/job-excluded-labels: "foo.bar/environment,foo.bar/version" labels: team: backend foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5 foo.bar/version: "1" ================================================ FILE: content/docs/2.18/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.18/deploy.md ================================================ +++ title = "Deploying KEDA" +++ KEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization. Using **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster. Each method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment. > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.30 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Prerequisites To deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features. If you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease. ### Installing 1. To deploy KEDA using Helm, first add the official KEDA Helm repository: ```sh helm repo add kedacore https://kedacore.github.io/charts helm repo update ``` 2. Install `keda` by running: **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods: ```sh kubectl get pods -n keda ``` To deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps: 1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version. 2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions: ```sh kubectl apply -f keda-2.xx.x-crds.yaml ``` Replace `2.xx.x` with the specific version number you downloaded. By deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process. > 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues. Deploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments. ### Uninstalling To uninstall KEDA, use the following Helm command: ```sh helm uninstall keda –namespace keda ``` This command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run: ```sh kubectl delete namespace keda ``` Uninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version. You can remove finalizers with the following command: ```sh kubectl patch scaledobject -p '{"metadata":{"finalizers":null}}' --type=merge kubectl patch scaledjob -p '{"metadata":{"finalizers":null}}' --type=merge ``` Replace \<*resource-name*\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster. ## Deploying with Operator Hub {#operatorhub} ### Prerequisites Before deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access. If you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub. ### Installing To deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed. Search for "KEDA" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace. 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) Using Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment. > 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository: > > [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator) > > This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments. > > For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful: > > \- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator. > > \- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster. > > \- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project. ### Uninstalling To uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster. If you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks. ## Deploying KEDA using the YAML files {#yaml} ### Prerequisites Before deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster. ### Installing Once the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command: ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3-core.yaml ``` Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.18.3.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.18.3-core.yaml ``` The `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740). > 💡 **NOTE:** If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally: > > ```sh > git clone https://github.com/kedacore/keda && cd keda > > VERSION=2.18.3 make deploy > ``` > > This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization. After applying the YAML, verify the deployment by checking the KEDA namespace: ```sh kubectl get pods -n keda ``` Deploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates. ### Uninstalling If you installed KEDA using the released YAML files, you can uninstall it by running the following commands: ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3-core.yaml ``` If you downloaded the files locally, uninstall with: ```sh # Including admission webhooks kubectl delete -f keda-2.18.3.yaml # Without admission webhooks kubectl delete -f keda-2.18.3-core.yaml ``` For users who cloned the KEDA GitHub repository, navigate to the cloned directory and use: ```sh VERSION=2.18.3 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Prerequisites Before deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`). Additionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons: * **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration. * **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation. ### Installing To install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on. 1. Enable Helm and DNS Add-ons (if not already enabled): ```sh microk8s enable dns helm3use ``` 2. Add the KEDA Helm Repository: ```sh microk8s helm3 repo add kedacore https://kedacore.github.io/charts microk8s helm3 repo update ``` 3. Install KEDA Using Helm. Deploy KEDA into your MicroK8s cluster by running: ```sh microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace ``` 4. Verify the Installation. Check that KEDA is running by listing the pods in the keda namespace: ```sh microk8s kubectl get pods -n keda ``` This approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development. ### Uninstalling To uninstall KEDA from your MicroK8s environment, disable the KEDA add-on: ```sh microk8s disable keda ``` This command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation. If you deployed KEDA using Helm, uninstall it with: ```sh microk8s helm3 uninstall keda --namespace keda ``` After running these commands, KEDA will be fully removed from your MicroK8s setup. ## Getting Started with KEDA: A Simple Example To help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This "Hello KEDA" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality. Before starting, ensure you have the following: * **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service. * **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster. * **KEDA Installed**: KEDA should be installed in your cluster. ### Step 1: Deploy a Sample Application We'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server. 1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: http-app spec: replicas: 1 selector: matchLabels: app: http-app template: metadata: labels: app: http-app spec: containers: - name: http-app image: hashicorp/http-echo args: - "-text=Hello, KEDA!" ports: - containerPort: 5678 ``` 2. **Apply the Deployment**: Run the following command to create the deployment: ```sh kubectl apply -f deployment.yaml ``` ### Step 2: Expose the Application To access the application, we'll create a Service. 1. **Create a Service Manifest**: Save the following YAML as `service.yaml`: ```yaml apiVersion: v1 kind: Service metadata: name: http-app-service spec: selector: app: http-app ports: - protocol: TCP port: 80 targetPort: 5678 type: LoadBalancer ``` 2. **Apply the Service**: Run the following command to create the service: ```sh kubectl apply -f service.yaml ``` 3. **Retrieve the External IP**: After a few moments, retrieve the external IP address: ```sh kubectl get service http-app-service ``` ### Step 3: Create a ScaledObject We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. 1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-app-scaledobject spec: scaleTargetRef: name: http-app minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: prometheus metadata: serverAddress: http://prometheus-server.default.svc.cluster.local:9090 threshold: '5' query: sum(rate(http_requests_total[1m])) ``` > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed. 2. **Apply the ScaledObject**: Run the following command to create the ScaledObject: ```sh kubectl apply -f scaledobject.yaml ``` ### Step 4: Test the Scaling Behavior We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. To observe KEDA's scaling in action: 1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP: ```sh hey -z 1m -c 10 http:// ``` Replace `` with the external IP address obtained earlier. 2. **Monitor Scaling:** Run the following command to watch the scaling behavior: ```sh kubectl get pods -w ``` You should see the number of pods increase as the load increases and decrease when the load subsides. ### Cleanup After completing the exercise, clean up the resources: ```sh kubectl delete -f scaledobject.yaml kubectl delete -f service.yaml kubectl delete -f deployment.yaml ``` This example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events. ================================================ FILE: content/docs/2.18/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.18/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.18/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.18/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). > Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.18/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.18/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance and requirements for operating KEDA" weight = 1 +++ We provide guidance and requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](../reference/events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.18/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ### Cache Miss with Fallback to Direct Client for ScaledObject When validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`: ``` --cache-miss-to-direct-client=true ``` This will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API. ## Custom Validations using Kubernetes ValidatingAdmissionPolicy > ⚠️ FEATURE STATE: Kubernetes v1.30 [stable] Kubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). Here is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10): ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-keda-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["keda.sh"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["scaledobjects"] validations: - expression: "object.spec.maxReplicaCount <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-keda-replicas-binding.example.com" spec: policyName: "limit-keda-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` Since KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas: ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-apps-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments", "replicasets"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-hpa-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["autoscaling"] apiVersions: ["v2"] operations: ["CREATE", "UPDATE"] resources: ["horizontalpodautoscalers"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-apps-replicas-binding.example.com" spec: policyName: "limit-apps-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-hpa-replicas-binding.example.com" spec: policyName: "limit-hpa-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` ================================================ FILE: content/docs/2.18/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | | `keda.scaledobject.removed.v1`| When a ScaledObject is deleted | | `keda.scaledjob.ready.v1`| On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledjob.failed.v1`| If the check validation for a ScaledJob fails | `keda.scaledjob.removed.v1`| When a ScaledJob is deleted | | `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created | | `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | | `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted | | `keda.authentication.clustertriggerauthentication.created.v1`| On the first time a ClusterTriggerAuthentication is created | | `keda.authentication.clustertriggerauthentication.updated.v1`| When a ClusterTriggerAuthentication is updated | | `keda.authentication.clustertriggerauthentication.removed.v1`| When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.18/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.19 | TBD | | v2.18 | v1.31 - v1.33 | | v2.17 | v1.30 - v1.32 | | v2.16 | v1.29 - v1.31 | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 on the KEDA operator deployment to your desired timeout in milliseconds. > ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata. ## 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ## Logs KEDA uses zap to emit logs. The following flags can be used to configure logging behavior in both the metrics-apiserver and operator: - zap-encoder: Zap log encoding (one of `json` or `console`). Default is `console` - zap-log-level: Zap Level to configure the verbosity of logging. Can be one of `debug`, `info`, `error`, or any integer value > 0 which corresponds to custom debug levels of increasing verbosity"). Default is `info`. - zap-time-encoding: Zap time encoding (one of `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano`), Defaults is `rfc3339`. ================================================ FILE: content/docs/2.18/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (external metrics only): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.18/operate/schema.md ================================================ +++ title = "Schema" description = "Specification & generation of KEDA scalers' schema" weight = 100 +++ ## Scaler Schema KEDA provides a separate scaler's schema for third-party usage ([scalers-metadata-schema.yaml](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.yaml)/[scalers-metadata-schema.json](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.json)). The schema file will keep updating according to the scaler's refactor. *Notice: The schema file still lacks some of the scalers. It will be completed once all scalers are refactored to use the new declarative scaler config. ## Specification Here is a the schema of the scalers: ``` kedaVersion: main schemaVersion: 1 scalers: - type: activemq parameters: - name: managementEndpoint type: string optional: true metadataVariableReadable: true - name: destinationName type: string optional: true metadataVariableReadable: true - name: brokerName type: string optional: true metadataVariableReadable: true - name: username type: string metadataVariableReadable: true envVariableReadable: true triggerAuthenticationVariableReadable: true - name: password type: string metadataVariableReadable: true envVariableReadable: true triggerAuthenticationVariableReadable: true - name: corsHeader type: string optional: true metadataVariableReadable: true - name: restAPITemplate type: string optional: true metadataVariableReadable: true - name: targetQueueSize type: string default: "10" metadataVariableReadable: true - name: activationTargetQueueSize type: string default: "0" metadataVariableReadable: true - type: apache-kafka parameters: - name: bootstrapServers ... ``` **Metadata field's property detail:** | Property | Description |--------------|------------ | name | the name of the field | type | type is the variable type of the field | optional | optional is a boolean that indicates if the field is optional | default | default is the default value of the field | allowedValue | allowedValue is a list of allowed values for the field | deprecated | deprecated is a string that indicates if the field is deprecated | deprecatedAnnounce | deprecatedAnnounce is a string that indicates the deprecation message | separator | separator is the symbol that separates the value of the field if the value is a list string | exclusiveSet | exclusiveSet is a list of fields that are exclusive with the field | rangeSeparator | rangeSeparator is the symbol that indicates the range of the field | metadataVariableReadable | metadataVariableReadable is a boolean that indicates if the field can be read from the environment | envVariableReadable | envVariableReadable is a boolean that indicates if the field can be read from the environment | triggerAuthenticationVariableReadable | triggerAuthenticationVariableReadable is a boolean that indicates if the field can be read from the trigger authentication ## Generation There are two ways to generate scaler schemas: 1. Run the GO file in the schema folder directly ``` go run schema/generate_scaler_schema.go parameters: --keda-version string Set the version of current KEDA in schema. (default "1.0") --kubeconfig string Paths to a kubeconfig. Only required if out-of-cluster. --output-file-path string scaler-metadata-schemas.yaml output file path. (default "./") --scalers-builder-file buildScaler The file that exists buildScaler func. (default "../pkg/scaling/scalers_builder.go") --scalers-files-dir string The directory that exists all scalers' files. (default "../pkg/scalers") --specify-scaler string Specify scaler name. ``` 2. Use makefile ``` make generate-scaler-schemas env variables: OUTPUT_FILE_PATH scaler-metadata-schemas.yaml output file path. (default "./") SCALERS_BUILDER_FILE The file that exists buildScaler func. (default "../pkg/scaling/scalers_builder.go") SCALERS_FILES_DIR The directory that exists all scalers' files. (default "../pkg/scalers") ``` SCALERS_BUILDER_FILE ?= "pkg/scaling/scalers_builder.go" SCALERS_FILES_DIR ?= "pkg/scalers" OUTPUT_FILE_PATH ?= "schema/" ================================================ FILE: content/docs/2.18/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). Additionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources. Example use case: - When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources. 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory. Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`. ================================================ FILE: content/docs/2.18/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.18/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScalerInfo` | `Normal` | When a Scaler contains deprecated field | | `KEDAScalerInfo` | `Warning` | When a Scaler contains unexpected parameter (disabled by default, enable with `KEDA_CHECK_UNEXPECTED_SCALERS_PARAMS`) | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.18/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_15" >}} ================================================ FILE: content/docs/2.18/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## gRPC Remote Procedure Calls (gRPC) gRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.18/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). **eager** When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible. For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours. ### pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: rabbitmq metadata: queueName: woker_queue hostFromEnv: RABBITMQ_URL mode: QueueLength value: "1" ``` We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 3 | If we switch to `eager`, the result becomes: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 6 | We can identify the difference in their final states. You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.18/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: {kind-of-behavior} # Optional. Default: "static" advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. When scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N. If you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: "static" # Optional. Default: "static" ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. Fallback is supported for all triggers of both `Value` and `AverageValue` metric types, except CPU & memory triggers. It's also only supported by `ScaledObjects`, not `ScaledJobs`. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula for `AverageValue` metrics: ``` target metric value * fallback replicas ``` For `Value` metrics it's using the formula: ``` target metric value * fallback replicas / current ready replicas ``` These formulas offset the HPA's calculations and will cause it to scale the deployment to the specified number of fallback replicas. ## fallback.behavior The `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used. #### `static` behavior When `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'. #### `currentReplicas` behavior When using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'. #### `currentReplicasIfHigher` behavior When using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'. #### `currentReplicasIfLower` behavior When using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 tolerance: 0.1 # requires Kubernetes v1.33 or newer and feature gate "HPAConfigurableTolerance" ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. #### horizontalPodAutoscalerConfig.behavior tolerance As of Kubernetes v1.34 the `tolerance` field can be specified under the HPA behavior policy `scaleUp` and `scaleDown` sections. The field applies a tolerance thresholds for scaling decisions, allowing you to specify different behavior for scale-up and scale-down operations. This field was in alpha release under Kubernetes v1.33, which can be enabled through the Kubernetes `HPAConfigurableTolerance` feature gate. As of Kubernetes v1.34, this field has graduated to beta release and is specifiable by default. ### scalingModifiers If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional). There is one important exception to the activation target for scaling modifiers and that is [external push scalers](../concepts/external-scalers). These scalers can implement `StreamIsActive` gRPC method which pushes activation status to KEDA directly, regardless of what the metric value and activation target is. #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.18/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.18/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.18/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false ensureEvenDistributionOfPartitions: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### New `ensureEvenDistributionOfPartitions` property support When scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to. Consider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution. Below are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default. - For lag between `1 -> 10` we would be running `1` consumer - For lag between `11 -> 20` we would be running `2` consumer - For lag between `21 -> 50` we would be running `5` consumers - For lag higher than `51` we would be running `10` consumers ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.18/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' ensureEvenDistributionOfPartitions: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### New `ensureEvenDistributionOfPartitions` property support When scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to. Consider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution. Below are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default. - For lag between `1 -> 10` we would be running `1` consumer - For lag between `11 -> 20` we would be running `2` consumer - For lag between `21 -> 50` we would be running `5` consumers - For lag higher than `51` we would be running `10` consumers ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.18/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Datastore" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.18/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. **TLS authentication:** - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - Password for the client certificate private key. (Optional, Required when `key` is encrypted) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ### Example with TLS (HTTPS with self-signed certificates) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8443" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" unsafeSsl: "true" # Skip certificate validation for self-signed certificates authenticationRef: name: trigger-auth-kedartemis ``` ### Example with mutual TLS (client certificates) ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis-tls namespace: kedartemis type: Opaque data: artemis-ca: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=" # Base64 encoded CA certificate artemis-cert: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=" # Base64 encoded client certificate artemis-key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi4uLgo=" # Base64 encoded client private key --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis-tls namespace: kedartemis spec: secretTargetRef: - parameter: ca name: kedartemis-tls key: artemis-ca - parameter: cert name: kedartemis-tls key: artemis-cert - parameter: key name: kedartemis-tls key: artemis-key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8443" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" authenticationRef: name: trigger-auth-kedartemis-tls ``` ================================================ FILE: content/docs/2.18/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Optional: ignoreNullValues ignoreNullValues: "false" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). Supports all CloudWatch statistics including percentiles (e.g., `p95`, `p50`) and trimmed means (e.g., `tm99`, `tm95`). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response. If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional) > Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload. - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.18/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.18/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.18/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.18/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.18/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.18/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.18/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) > When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.18/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" # Optional. Custom timeout for the HTTP client used in this scaler timeout: "1000" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides ### Links - [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) - [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity) - [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity) ================================================ FILE: content/docs/2.18/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "0.5" activationTargetValue: "3.5" activeDirectoryClientId: # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.18/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: Require jobs to include specified demands, ignoring any extra ones requireAllDemandsAndIgnoreOthers: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" # Optional: Whether to only fetch unfinished jobs from the API (default: false) fetchUnfinishedJobsOnly: false # Optional: Property to enable case-insensitive comparison of pipeline job demands (default: false) caseInsensitiveDemandsProcessing: false authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME". Mutually exclusive with `jobsToFetch`. - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API. Mutually exclusive with `parent` and `fetchUnfinishedJobsOnly`. (Default: `250`, Optional) - `fetchUnfinishedJobsOnly` - Whether to fetch only unfinished jobs from the Azure Pipeline API. Normally both finished, running and pending jobs are returned by the API. When this parameter is set to `true`, the API call is modified so that only running and pending jobs are returned from the API, which reduces the amount of returned jobs considerably. Mutually exclusive with `jobsToFetch`. (Default: `false`, Optional) - `caseInsensitiveDemandsProcessing` - Property to enable case-insensitive comparison of pipeline job demands. When this parameter is set to `true`, the demands check is case-insensitive. (Default: `false`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not use demands in your agent scaler then it scales based on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list. - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. However, as this an undocumented API, it possesses some unique quirks when calling it with different query parameters. For example, if the `$top` query parameter is given, the format of the returned JSON is changed in such a way that it is no longer possible for the scaler to find the matched agents; making it impossible to use with the `parent` property from the trigger metadata. Therefore making `jobsToFetch` mutually exclusive with `parent` in the trigger metadata. Additionally, the `$top` query parameter takes precedence over some other parameters like `completedRequestCount`. If the `$top` query parameter is given, finished jobs are included in the response even if `completedRequestCount=0` is given, although `completedRequestCount=0` would indicate that only pending and running jobs should be returned. Thus, `jobsToFetch` is also mutually exclusive with `fetchUnfinishedJobsOnly` in the trigger metadata. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.18/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.18/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.18/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' queueLengthStrategy: all|visibleonly activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 # Optional queueLengthStrategy: "all" # or visibleonly. Default: all cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.18/scalers/beanstalkd.md ================================================ +++ title = "Beanstalkd" availability = "v2.16+" maintainer = "Community" description = "Scale applications based on beanstalkd queues" go_file = "beanstalkd_scaler" +++ ### Trigger Specification This specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue. ```yaml triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 includeDelayed: "false" tube: "default" activationValue: "10" value: "15" timeout: "30" ``` **Parameter list:** - `server` - Address of beanstalkd server `:`. If no port is specified then the scaler will default to `11300`. - `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted. - `tube` - Name of the tube to scale on. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set. - `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional) ### Authentication Parameters No authentication should be needed to connect to the beanstalkd server. ### Example #### Default tube with activation value Here the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'default' activationValue: "10" value: "20" ``` #### User-created tube with minimum replicas A minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'scaling-tube' value: "5" includeDelayed: "true" ``` ================================================ FILE: content/docs/2.18/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. - `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional). - `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional) - `key` - Key path for client authentication. Mandatory if tls enabled. (Optional) ### Example with no TLS auth ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ### Example with TLS auth Since we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes: - name: temp-cassandra-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes.keda.extraVolumes - name: temp-cassandra-vol emptyDir: medium: Memory ``` Once we have the writable mount path set up for the certificates and keys. ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD tls: enable cert: key: ## Optional parameter ca ## ca: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password - parameter: tls name: cassandra-secrets key: tls - parameter: cert name: cassandra-secrets key: cert - parameter: key name: cassandra-secrets key: key ## Optional parameter ca ## - parameter: ca name: cassandra-secrets key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.18/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.18/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.18/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be the same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale your deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do it the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.18/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). There are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately. ## Using the Datadog Cluster Agent (Experimental) With this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches. ### Deploy the Datadog Cluster Agent with enabled external metrics First, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA). If you are using Helm to deploy the Cluster Agent, set: * `clusterAgent.metricsProvider.enabled` to `true` * `clusterAgent.metricsProvider.registerAPIService` to `false` * `clusterAgent.metricsProvider.useDatadogMetrics` to `true` * `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}]` If you are using the Datadog Operator, add the following options to your `DatadogAgent` object: ``` apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: name: datadog spec: features: externalMetricsServer: enabled: true useDatadogMetrics: true registerAPIService: false override: clusterAgent: env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}] [...] ``` NOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later. ### Create a DatadogMetric object for each scaling query To use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: "true"` annotation, to ensure the Cluster Agent retrieves the query value. Example: ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: annotations: external-metrics.datadoghq.com/always-active: "true" name: nginx-hits spec: query: sum:nginx.net.request_per_s{kube_deployment:nginx} ``` ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType metricUnavailableValue: "1.5" timeout: "10s" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional) - `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events. - `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events. - `targetValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) - `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication The Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below: **Common to all authentication types** - `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional) - `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed. - `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern. - `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional) **Bearer authentication:** - `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated. ### Example ```yaml apiVersion: v1 kind: ConfigMap metadata: name: datadog-config namespace: my-project data: datadogNamespace: # Required: namespace where the Datadog Cluster Agent is deployed datadogMetricsService: # Required: Cluster Agent metrics server service name unsafeSsl: # Optional: set to "true" to skip SSL certificate validation authMode: # Required: authentication mode (bearer) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: datadog-cluster-agent-creds namespace: my-project spec: boundServiceAccountToken: - parameter: token serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io configMapTargetRef: - parameter: datadogNamespace name: datadog-config key: datadogNamespace - parameter: unsafeSsl name: datadog-config key: unsafeSsl - parameter: authMode name: datadog-config key: authMode - parameter: datadogMetricsService name: datadog-config key: datadogMetricsService --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx maxReplicaCount: 3 minReplicaCount: 1 pollingInterval: 60 triggers: - type: datadog metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "2" type: "global" timeout: "10s" authenticationRef: name: datadog-cluster-agent-creds ``` ## Using the Datadog REST API ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "false" query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" timeout: "10s" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false) - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) - `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" # Optional: the HTTP timeout for this trigger timeout: "10s" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ### Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../reference/scaledobject-spec/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ### Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. #### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. #### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ### Cases of unexpected metrics value in DataDog API response #### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue #### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.18/scalers/dynatrace.md ================================================ +++ title = "Dynatrace" availability = "2.15+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Dynatrace metric data points" go_file = "dynatrace_scaler" +++ ### Trigger Specification This specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points. ```yaml triggers: - type: dynatrace metadata: host: https://dummy-instance.live.dynatrace.com/ metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' # Optional from: now-2d threshold: "10" # Optional activationThreshold: "5" ``` **Parameter list:** - `host` - The Dynatrace instance to query against - `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). Some relevant aspects: - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector - `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters. **Authentication:** - `host` - The Dynatrace instance to query against - `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/ token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' from: 'now-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ================================================ FILE: content/docs/2.18/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html). The trigger always requires the following information, but requires either only searchTemplateName **or** only query: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" query: "my-query" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `query` - The query to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Examples Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" query: | { "size": 0, "query": { "bool": { "must": [ { "term": { "service.name": "my-application" } }, { "term": { "service.environment": "production" } }, { "range": { "@timestamp": { "gte": "now-2m", "lte": "now-1m" } } } ] } }, "aggs": { "transaction_count": { "cardinality": { "field": "transaction.id" } } } } valueLocation: "aggregations.transaction_count.value" targetValue: "1000" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.18/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' usernameFromEnv: # Optional passwordFromEnv: # Optional ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Password based authentication:** - `username` - Username for authentication. (Optional) - `password` - Password for authentication. (Optional) **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on Password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: etcd-username: etcd-password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-etcd-secrets key: etcd-username - parameter: password name: keda-etcd-secrets key: etcd-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.18/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.18/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem enableTLS: false unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.18/scalers/forgejo.md ================================================ +++ title = "Forgejo" availability = "v2.18+" maintainer = "Community" category = "CI/CD" description = "Scale applications based on pending jobs on Forgejo repository." go_file = "forgejo_scaler" +++ ### Trigger Specification This specification describes the `forgejo-runner` trigger for Forgejo Actions. It scales based on the amount of jobs pending in given runner labels. ```yaml triggers: - type: forgejo-runner metadata: # Required: the name of the registered runner name: "forgejo-runner-ubuntu" # Required: the url of the forgejo instance address: "http://localhost:3000" # Optional: Scope of the jobs to check, global is the default one and will get all the jobs in the instance with the defined labels global: "true" # Optional: User to set as a scope, global should be false, if no repo is set will get all the pending jobs for the user owner: "cobak" # Optional: Repository level scope repo: "my-repo" # Required: Will get the jobs with match with this labels labels: "ubuntu-latest" ``` **Parameter list:** - `name` - Name of the registered runner. - `address` - Url of the forgejo instance. - `global` - Scope of the jobs to check. (Values: `true`, `false`, Default: `true`, Optional, Mutually exclusive with `owner` and `repo`) - `owner` - User to set as a scope. (Optional, Mutually exclusive with `global` and `repo`) - `repo` - User to set as a scope. (Optional, Mutually exclusive with `global` and `owner`) - `labels` - Labels to match the job with. ### Authentication Parameters - `token` - Required token to connect to forgejo instance. ### Options on how to set the scope (global, user, repo) 1. If you set owner and repo KEDA forgejo scaler will retrieve jobs from that repository: ``` owner: "username" repo: "my_repo" ``` 2. If you set the organization will retrieve the organization jobs: ``` org: "my_org" ``` 3. If you set global: true will retrieve all the jobs from the instance ``` global: "true" ``` 4. And if you don't set any of this optional fields will retrieve the jobs from the user who creates the token ## Configuration ### Registering runners and binding config with autoscalers To match job endpoints with job execution, we need to pre-register a runner, save the generated JSON file as a ConfigMap, and share it with the autoscaler. review the different ways to register a runner [here](https://forgejo.org/docs/latest/admin/runner-installation/#standard-registration), select the desired scope (user, repository or global) and create the corresponding JSON file. Autoscaler definition and runner registration should match to work as expected. Create a .runner file and a registration file with this commands, and set the output in a configmap. ```shell docker run -v /var/run/docker.sock:/var/run/docker.sock -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner register --no-interactive --token xxxx --name runner --instance http://localhost:3000/ --labels ubuntu-20:docker://node:20-bookworm,docker:docker://ghcr.io/catthehacker/ubuntu:act-latest docker run -v /var/run/docker.sock:/var/run/docker.sock -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner generate-config > registration.yaml ``` ```yaml apiVersion: v1 kind: ConfigMap metadata: name: runner-config namespace: runners data: .runner: | { "WARNING": "This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.", "id": 3, "uuid": "be6b5260-e73f-4e21-af84-8e205dbaaacd", "name": "runner", "token": "", "address": "http://localhost:3000/", "labels": [ "ubuntu-20:docker://node:20-bookworm", "docker:docker://ghcr.io/catthehacker/ubuntu:act-latest" ] } --- apiVersion: v1 kind: ConfigMap metadata: name: runner-registration namespace: runners data: registration.yaml: | log: # The level of logging, can be trace, debug, info, warn, error, fatal level: info # The level of logging for jobs, can be trace, debug, info, earn, error, fatal job_level: info runner: # Where to store the registration result. file: /data/.runner # Execute how many tasks concurrently at the same time. capacity: 1 # Extra environment variables to run jobs. envs: DOCKER_HOST: tcp://localhost:2376 DOCKER_TLS_VERIFY: 1 DOCKER_CERT_PATH: /certs/client # Extra environment variables to run jobs from a file. # It will be ignored if it's empty or the file doesn't exist. env_file: .env # The timeout for a job to be finished. # Please note that the Forgejo instance also has a timeout (3h by default) for the job. # So the job could be stopped by the Forgejo instance if it's timeout is shorter than this. timeout: 3h # The timeout for the runner to wait for running jobs to finish when # shutting down because a TERM or INT signal has been received. Any # running jobs that haven't finished after this timeout will be # cancelled. # If unset or zero the jobs will be cancelled immediately. shutdown_timeout: 3h # Whether skip verifying the TLS certificate of the instance. insecure: false # The timeout for fetching the job from the Forgejo instance. fetch_timeout: 5s # The interval for fetching the job from the Forgejo instance. fetch_interval: 2s # The interval for reporting the job status and logs to the Forgejo instance. report_interval: 1s # The labels of a runner are used to determine which jobs the runner can run, and how to run them. # Like: ["macos-arm64:host", "ubuntu-latest:docker://node:20-bookworm", "ubuntu-22.04:docker://node:20-bookworm"] # If it's empty when registering, it will ask for inputting labels. # If it's empty when executing the `daemon`, it will use labels in the `.runner` file. labels: - ubuntu-20:docker://node:20-bookworm - docker:docker://ghcr.io/catthehacker/ubuntu:act-latest cache: # Enable cache server to use actions/cache. enabled: true # The directory to store the cache data. # If it's empty, the cache data will be stored in $HOME/.cache/actcache. dir: "" # The host of the cache server. # It's not for the address to listen, but the address to connect from job containers. # So 0.0.0.0 is a bad choice, leave it empty to detect automatically. host: "" # The port of the cache server. # 0 means to use a random available port. port: 0 # The port of the cache proxy. # 0 means to use a random available port. proxy_port: 0 # The external cache server URL. Valid only when enable is true. # If it's specified, it will be used to set the ACTIONS_CACHE_URL environment variable. The URL should generally end with "/". # Otherwise it will be set to the the URL of the internal cache server. external_server: "" # The shared cache secret. When communicating with a cache server, the runner uses this secret to verify the authenticity of the cache requests. # When using an external cache server it is required to set the same secret for the runner and the cache server. secret: "" # Overrides the ACTIONS_CACHE_URL passed to workflow containers. This should only be used if the runner host is not reachable from the # workflow containers, and requires further setup. actions_cache_url_override: "" container: # Specifies the network to which the container will connect. # Could be host, bridge or the name of a custom network. # If it's empty, create a network automatically. network: host # Whether to create networks with IPv6 enabled. Requires the Docker daemon to be set up accordingly. # Only takes effect if "network" is set to "". enable_ipv6: false # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker). privileged: false # And other options to be used when the container is started (eg, --add-host=my.forgejo.url:host-gateway). options: -v /certs/client:/certs/client # The parent directory of a job's working directory. # If it's empty, /workspace will be used. workdir_parent: # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted. # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to: # valid_volumes: # - data # - /src/*.json # If you want to allow any volume, please use the following configuration: # valid_volumes: # - '**' valid_volumes: - /certs/client # overrides the docker client host with the specified one. # If "-" or "", an available docker host will automatically be found. # If "automount", an available docker host will automatically be found and mounted in the job container (e.g. /var/run/docker.sock). # Otherwise the specified docker host will be used and an error will be returned if it doesn't work. docker_host: "-" # Pull docker image(s) even if already present force_pull: false # Rebuild local docker image(s) even if already present force_rebuild: false host: # The parent directory of a job's working directory. # If it's empty, $HOME/.cache/act/ will be used. workdir_parent: ``` ### Create a token on forgejo The autoscaler will continuously fetch new waiting jobs from Forgejo, so it requires a properly configured token with the appropriate permissions. Navigate to **Forgejo > User settings > Applications > Access Tokens** and generate a new token. This token will be used by the autoscaler ### Configuring KEDA Autoscaler Create a new custom resource with the required parameters and custom fields based on the scope chosen during runner registration. For example, set `global="true"` for global runners or specify `repo=xxx` and `owner=xxx` for repository level runners. Choose the runner image you want to use (>6.1 of forgejo runner releases) or a custom one with `--one-job` command. Apply the new custom resource to your cluster. ```yaml apiVersion: v1 kind: Secret metadata: name: forgejo-runner-secret namespace: runners data: token: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: forgejo-runner-creds namespace: runners spec: secretTargetRef: - parameter: token name: forgejo-runner-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: labels: app: forgejo-runner name: upload-platform-forgejo-runner namespace: runners spec: jobTargetRef: template: metadata: labels: app: forgejo-runner spec: volumes: - name: runner-data emptyDir: {} - name: runner-config configMap: name: upload-platform-runner-config - name: runner-registration configMap: name: upload-platform-runner-registration - name: docker-certs emptyDir: {} restartPolicy: Never shareProcessNamespace: true containers: - name: runner image: code.forgejo.org/forgejo/runner:6.3.1 command: - sh - -c - | while ! nc -z localhost 2376 &1 & while kill -0 7 2>/dev/null do sleep 10 echo "watching main job execution" done; sleep 10 echo "main container exited, stopping dind" exit 0 env: - name: DOCKER_TLS_CERTDIR value: /certs - name: DOCKER_HOST value: tcp://0.0.0.0:2376 securityContext: privileged: true runAsUser: 0 volumeMounts: - name: docker-certs mountPath: /certs minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: forgejo-runner metadata: name: "runner" address: "http://localhost:3000/" global: "true" labels: "ubuntu-20,docker" authenticationRef: name: forgejo-runner-creds ``` ================================================ FILE: content/docs/2.18/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 filterDuration: '1' # Optional - Default is 2 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.18/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # The 'subscriptionSize' setting is DEPRECATED and will be removed in v2.20 - Use 'mode' and 'value' instead" mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 valueIfNull: '0.0' # Optional - Default is "" activationValue: "10.5" # Optional - Default is 0 timeHorizon: "1m" # Optional - Default is 2m and with aggregation 5m # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`) - `valueIfNull` - Value returned if request returns no timeseries.(Default: `""`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.18/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" filterDuration: '1' # Optional - Default is 2 activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.18/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.18/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false", defaults to "false" (scale on default runner labels) noDefaultLabels: "{noDefaultLabels}" # Optional: When enabled unlabeled jobs will not match unlabeled runners. Can be either "true" or "false", defaults to "false" matchUnlabeledJobsWithUnlabeledRunners: "{matchUnlabeledJobsWithUnlabeledRunners}" # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either "true" or "false", defaults to "false" enableEtags: "{enableEtags}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabels` - Not scale on default runner labels ("self-hosted", "linux", "x64"). (Values: `true`,`false`, Default: "false", Optional) - `matchUnlabeledJobsWithUnlabeledRunners` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: "false", Optional) - `enableEtags` - Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabelsFromEnv` - Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false". (Optional) - `matchUnlabeledJobsWithUnlabeledRunnersFromEnv` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations: - Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories. - Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **Fine-Tuning** The current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters. For example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly. *Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).* At the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.18/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.18/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) (**The 'minMetricValue' setting is DEPRECATED and will be removed in v2.20 - Use 'activationTargetMetricValue' instead**) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.18/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret unsafeSsl: "false" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ). - `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example Example with Basic Auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` Example with Basic Auth and TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password cert: key: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD - parameter: cert name: keda-ibmmq-secret key: cert - parameter: key name: keda-ibmmq-secret key: key ``` ================================================ FILE: content/docs/2.18/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org # Required for InfluxDB v2.x, optional for InfluxDB v3.x organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") metricKey: 'mymetric' # Required for Influx v3. Ignored for v2. See details in "Parameter List" section queryType: 'InfluxQL' # Required for Influx v3. Ignored for v2. See details in "Parameter List" section influxVersion: '2' # Optional: Defaults to 2. database: 'some-influx-db' # Required for Influx v3 authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc (Optional, Required if `influxVersion: '2'`). - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `influxVersion` - Specifies the version of InfluxDB being used. (Values: `2`, `3`, Default: `2`, Optional) - `database` - The name of the InfluxDB database to query. Required for InfluxDB v3.x. (Optional for InfluxDB v2.x) - `metricKey` - The name of the metric to be used for scaling decisions. This is required for InfluxDB v3.x and ignored for InfluxDB v2.x. It is used to identify the metric in the query results. For a `query` of `SELECT mean("mymetric") AS "metric_name" FROM...` use `metricKey: 'metric_name'`. (Optional, Required if `influxVersion: '3'`) - `queryType` - Specifies the type of query being used. For InfluxDB v3.x, this can be either `InfluxQL` or `FlightSQL`. For InfluxDB v2.x, this parameter is ignored. (Values: `InfluxQL`, `FlightSQL`, Default: `InfluxQL`, Optional) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example (InfluxDB v2) Below is an example of how to deploy a scaled object with the `InfluxDB` (v2) scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ### Example (InfluxDB v3) Below is a similar example for Influx v3 using an `InfluxQL` query. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 database: 'my-metrics-db' influxVersion: '3' queryType: 'InfluxQL' metricKey: 'mean' thresholdValue: '2' activationThresholdValue: '10' query: | SELECT mean("water_level") FROM "h2o_feet" GROUP BY time(5m) ORDER BY time DESC LIMIT 1; authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.18/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.18/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.18/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.18/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.18/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.18/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. This value can be a float. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.18/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.18/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.18/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.18/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ > **Notice:** > The Stan scaler (NATS Streaming) is DEPRECATED and will be removed in v2.19 - Use scaler [nats-jetstream](./nats-jetstream.md) instead. > See also the deprecation notice [here](https://nats-io.gitbook.io/legacy-nats-docs/nats-streaming-server-aka-stan). ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. **TLS Authentication** - `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### Example without any TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with no TLS ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` #### Example with TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-stan-secrets namespace: default data: tls: enable ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: default spec: secretTargetRef: - parameter: tls name: keda-stan-secrets key: tls - parameter: ca name: keda-stan-secrets key: ca - parameter: cert name: keda-stan-secrets key: cert - parameter: key name: keda-stan-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "true" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.18/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example Autoscaling trigger based on transaction duration average metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` Autoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO" noDataError: "true" threshold: '300' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.18/scalers/nsq.md ================================================ +++ title = "NSQ" availability = "v2.17+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NSQ topic/channel depth." go_file = "nsq_scaler" +++ ### Trigger Specification This specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. ```yaml triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" useHttps: "false" unsafeSsl: "false" ``` **Parameter list:** - `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `:`. - `topic` - Name of the NSQ datastream that the `channel` relates to. - `channel` - Name of the channel used to calculate depth. - `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional) - `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional) - `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) > **Notice:** > - Since ["channels are created on first use by subscribing to the named channel"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0. > - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nsq-scaledobject spec: scaleTargetRef: name: nsq-consumer-deployment triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" ``` ================================================ FILE: content/docs/2.18/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.18/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.18/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for three connection options: A user can offer a full connection string (often in the form of an environment variable secret). - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. It is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity. More details and an example are provided down below. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` **Azure Access Token authentication:** #### Prerequisites: - The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity). - The UAMI should be granted access to the table mentioned in the query performed by KEDA. This can be achieved by: - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role. - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like `GRANT ALL ON TO "";`. Next, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process. - `host` - FQDN of the Azure Postgres Flexible Server. - `userName` - Name of the UAMI Azure identity (``). - `port` - Postgresql port (the default value is `"5432"`, please have a look at the `Remarks` down below). - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database (the value should be `require`). #### Remarks - While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-pg-flex-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql authenticationRef: name: azure-pg-flex-auth metadata: host: port: "5432" userName: dbName: sslmode: require query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.18/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.18/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint timeout: "1000" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.18/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.18/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://:/ # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either `amqp`, `http`, or `auto` for auto-detection based on the `host` value. Default value is `auto`. mode: QueueLength # Supported modes are `QueueLength`, `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` or `ExpectedQueueConsumptionTime` value: "100.50" # A value defining the threshold (per instance) that, when exceeded, triggers the scaling. activationValue: "10.5" # Optional. Activation threshold, which by default is 0. queueName: testqueue # Name of the queue. vhostName: / # Optional. If not specified, use the VHost in the `host` connection string. Required for Azure AD Workload Identity authorization (see below). # You can use existing environment variables to read configuration from. For details see "Parameters list" section. hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter. usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of `TriggerAuthentication`. passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of `TriggerAuthentication`. unsafeSsl: true # Optional. Whether to allow unsafe SSL connections. timeout: 1000 # Optional. Custom timeout for the HTTP client used in this scaler. ``` **Parameters list:** - `host` - RabbitMQ host address in the format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example, the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain `vhost`, then the trailing slash is required, e.g. `http://guest:password@localhost:5672/`. When using a username with password consider using `hostFromEnv` or a `TriggerAuthentication`. - `queueName` - Name of the queue to read required information and stats from. - `mode` - Trigger mode. See [Choosing the right trigger mode](#choosing-the-right-trigger-mode) for additional details. Can be one of: - `QueueLength` - trigger on number of messages in the queue - `MessageRate` - trigger on the publishing rate reported by the queue - `DeliverGetRate` - trigger on the rate of delivered messages (to consumers or in response to `basic.get`, both acknowledged and not) reported by the queue - `PublishedToDeliveredRatio` - trigger on the value of ratio of `MessageRate` to `DeliverGetRate` - `ExpectedQueueConsumptionTime` - trigger on the value of expected time (in seconds) of consumption of all messages currently available in the queue (utilizes `QueueLength`, `MessageRate` and `DeliverGetRate` metrics). - `value` - A value defining the threshold (per instance) that, when exceeded, triggers the scaling (can be a floating-point number depending on the trigger mode). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) (default: `0`; optional; can be a floating-point number). - `protocol` - Protocol to be used for communication (values: `auto`, `http`, `amqp`; default: `auto`; optional). - `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (it's optional by default but **it is required** if Azure AD Workload Identity authorization is used). - `queueLength` - **DEPRECATED: please use `mode: QueueLength` and `value: ##` instead**. Defines a threshold value for the queue length passed to the scaler. For example: if one pod can handle 10 messages, set the queue length target to `10`. If the actual number of messages in the queue is 30, the scaler will scale up to 3 pods. Default is set to `20` unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of using full name (values: `true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol). - `pageSize` - This parameter allows setting the page size (default: `100`; optional; only applies when `useRegex` is set to `true`). - `operation` - Operation that will be applied to compute the number of messages in case when `useRegex` is enabled (values: `sum`, `max`, `avg`; defaults: `sum`; optional). - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT` (optional; only applies to hosts that use the `http` protocol). - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (ready messages only; values:`true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol). - `unsafeSsl` - Whether to allow unsafe SSL connections (values: `true`, `false`, default: `false`). Some parameters can be provided using environment variables instead of setting them directly in metadata: - `hostFromEnv` - reads the host and port of the RabbitMQ server from selected environment variable (in similar format as `host` parameter) - `usernameFromEnv` - reads the username from selected environment variable, which is used to connect to the broker’s management endpoint - `passwordFromEnv` - reads the password from selected environment variable, which is used to connect to the broker’s management endpoint. > 💡 **Notes:** > - `host`/`hostFromEnv` has an optional VHost name after the host slash which will be used to scope API request > - when using `host`/`hostFromEnv` or `TriggerAuthentication`, the supplied password cannot contain special characters > - trigger modes `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` require `http` protocol. > - setting `useRegex` to `true` also requires `protocol` to be set to `http`. > ⚠ **Important:** > - If you have unacknowledged messages and you want to have these counted for the scaling to happen, make sure to utilize the `http` protocol (only REST API interface allows for these to be counted). > - If scaling against many is desired, then the `ScaledObject` should have all desired triggers defined. HPA will scale based on the largest result considering each of triggers independently. ### Choosing the right trigger mode Below you can find available trigger modes with most common usage scenarios: - `QueueLength` - Mainly used to scale messages consuming services, where it is desired to keep number of messages in the queue at selected, nominal level. - `MessageRate` - Mainly used to scale messages consuming services, where it is desired to keep the consumption rate up to messages publication rate (or higher). - `DeliverGetRate` - This specific trigger is actually a byproduct of the resulting implementation of `PublishedToDeliveredRatio` trigger (it was implemented to be used within `scalingModifiers` as a part of composite metric), yet it still has its use in some scenarios. E.g. assuming there's a well known consumer service performance ballpark, `DeliverGetRate` trigger can be utilized to scale out messages publishing service in order to increase publication rate. In this particular example however, upper publication rate limit must be properly guarded by another trigger or by [`maxReplicaCount`](./../reference/scaledobject-spec/#maxreplicacount) so as not to scale infinitely (which could result in overloading the broker, or consumers, or both). - `PublishedToDeliveredRatio` - This trigger is used mainly to control consumer pods scaling to keep publishing and consuming rates at stable level. Assuming that this is the case, the principle of operation is this: - if publishing rate is greater than `value` (usually it is a value slightly above `1`), trigger will initiate scale-out process to launch more consumer pods - if publishing rate is equal to consumption rate (value `1`) then it is the indicator that capacity of consumers is sufficient for handling ongoing messages processing and no additional pods need to be added to the pool - if ratio is below `1`, HPA can gracefully take down some consumers but keep messages processing rate at stable level. - `ExpectedQueueConsumptionTime` - A trigger primarily used to scale consumer pods, which uses estimate value of pending time to deliver all available messages in the queue to the consumers. If it becomes active in this particular scenario, returned metric indicates growing number of messages due either increased publishing rate or degraded performance of currently active number of consumers. It relies on proper setting of `pollingInterval` (see below for details). > ⚠ **Important:** > - With `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` it is advised to set `metricType: Value` in the trigger configuration to rely on absolute metric value and not the average value across all scaled pods. For reference see [`triggers.metricType`](./../reference/scaledobject-spec/#triggers) and [`scalingModifiers.metricType`](./../reference/scaledobject-spec/#scalingmodifiersmetrictype). > - When using `PublishedToDeliveredRatio`, having stable publication to consumption rate may not indicate that consumers pool is of the right size to do the job, since the messages consuming capabilities can change over time, which may result in much higher number of consumers than actually needed. It is then recommended to periodically re-evaluate consumers pool size using different, probably external metric (e.g. consumers count number, size of prefetch buffer, consumer performance, etc.). > - Since `ExpectedQueueConsumptionTime` trigger mode is based on the expected time (in seconds) for the selected queue to be emptied of all messages (including estimated count of published messages during sample probing), it must be served with `pollingInterval` set to 1 second. However, in case where such frequent polling may be expensive, it is recommended to use `ExpectedQueueConsumptionTime` in `scalingModifiers` using additional triggers values in formula like so: `(ExpectedQueueConsumptionTime - (QueueLength / DeliverGetRate)) * pollingInterval + (QueueLength / DeliverGetRate)`. ### Authentication Parameters `TriggerAuthentication` CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. - `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (optional, but **required** if Azure AD Workload Identity authorization is used). #### Username and Password based authentication This allows sensitive credentials to be stored and managed separately from the connection string: - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** If username or password are set in `TriggerAuthentication` or environment variables, they will override any credentials provided in the `host` parameter. #### TLS authentication - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ will not be used. Valid values are `enable` or `disable` (optional; the default is `disable`). - `ca` - Certificate authority file for TLS client authentication (optional). - `cert` - Certificate for client authentication (optional). - `key` - Certificate Key for client authentication (optional). > 💡 **Note:** Using RabbitMQ host with AMQPS protocol will require enabling the TLS settings and passing the required parameters. #### Azure Workload Identity authentication For RabbitMQ with OIDC support (>= 3.11) you can use `TriggerAuthentication` CRD with `podIdentity.provider = azure-workload` and with `workloadIdentityResource` parameter, which will hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Currently, only HTTP protocol is supported for AKS Workload Identity. ### Configuration examples #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672 vhostName: vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: vhostName name: keda-rabbitmq-secret key: vhostName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQP protocol with username and password authorization: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://localhost:5672/vhost (no username/password) username: # base64 encoded value of username password: # base64 encoded value of password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: username name: keda-rabbitmq-secret key: username - parameter: password name: keda-rabbitmq-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS authorization: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `MessageRate` and `QueueLength` triggers): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger) and enabled `useRegex`: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `DeliverGetRate` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value metadata: protocol: http queueName: testqueue mode: DeliverGetRate value: "30" authenticationRef: name: rabbitmq-trigger-auth ``` #### HTTP protocol (with `PublishedToDeliveredRatio` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value metadata: protocol: http queueName: testqueue mode: PublishedToDeliveredRatio value: "1.1" authenticationRef: name: rabbitmq-trigger-auth ``` #### HTTP protocol (with `PublishedToDeliveredRatio` trigger used together with `scalingModifiers`) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value name: p2d_ratio metadata: protocol: http queueName: testqueue mode: PublishedToDeliveredRatio value: "1" authenticationRef: name: rabbitmq-trigger-auth - type: rabbitmq name: qlen metadata: protocol: http queueName: testqueue mode: QueueLength value: "100" authenticationRef: name: rabbitmq-trigger-auth advanced: # Bind QueueLength and PublishedToDeliveredRatio together to control trigger value scalingModifiers: metricType: Value # Trigger if either one of conditions is met: # - publishing to delivery rate exceeds factor of 1.2 # - queue length contains more than 1.2K messages formula: "max(p2d_ratio, qlen/1000)" target: 1.2 ``` #### HTTP protocol (with `ExpectedQueueConsumptionTime` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment pollingInterval: 1 triggers: - type: rabbitmq metricType: Value name: eqct metadata: protocol: http queueName: testqueue mode: ExpectedQueueConsumptionTime value: "20" authenticationRef: name: rabbitmq-trigger-auth ``` ================================================ FILE: content/docs/2.18/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.18/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.18/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.18/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.18/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "myprimary" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.18/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.18/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars, SeleniumHQ" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration with default values represent. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: '' # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`). browserVersion: '' # Optional. platformName: '' # Optional. unsafeSsl: false # Optional. activationThreshold: 0 # Optional. nodeMaxSessions: 1 # Optional. enableManagedDownloads: true # Optional. capabilities: '' # Optional. ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional). - `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional). - `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional) **Trigger Authentication** - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional) - `accessToken` - Access token. This is required when `authType` is set a value. (Optional) ### Example --- #### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion` Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' ``` Noted: - From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details. The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` With above script, the request is sent to Grid. Via GraphQL response, it looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 0, "totalSlots": 0 }, "nodesInfo": { "nodes": [] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` In Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata. When the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 1, "totalSlots": 1 }, "nodesInfo": { "nodes": [ { "id": "UUID-of-Node", "status": "UP", "sessionCount": 0, "maxSession": 1, "slotCount": 1, "stereotypes": "[{\"slots\": 1, \"stereotype\": {\"browserName\": \"chrome\", \"browserVersion\": \"\", \"platformName\": \"Linux\"}}]", "sessions": [] } ] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` Now, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in. --- #### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName` Moreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome-131 labels: deploymentName: selenium-node-chrome-131 spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:131.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '131.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-131 namespace: keda labels: deploymentName: selenium-node-chrome-131 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-131 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '131.0' unsafeSsl: 'true' ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '131.0') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` #### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads` In image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS value: "true" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Scaler trigger param configuration should be aligned with Node stereotype. enableManagedDownloads: "true" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid options.enable_downloads = True driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata with extra `capabilities` For an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options - name: SE_NODE_STEREOTYPE_EXTRA value: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536 capabilities: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes options.set_capability('myApp:version', 'beta') options.set_capability('myApp:publish', 'public') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Firefox browser ```yaml kind: Deployment metadata: name: selenium-node-firefox labels: deploymentName: selenium-node-firefox spec: replicas: 1 template: spec: containers: - name: selenium-node-firefox image: selenium/node-firefox:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-firefox namespace: keda labels: deploymentName: selenium-node-firefox spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-firefox triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = FirefoxOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Edge browser Similarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml kind: Deployment metadata: name: selenium-node-edge labels: deploymentName: selenium-node-edge spec: replicas: 1 template: spec: containers: - name: selenium-node-edge image: selenium/node-edge:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-edge namespace: keda labels: deploymentName: selenium-node-edge spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-edge triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = EdgeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions` In case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' - name: SE_NODE_OVERRIDE_MAX_SESSIONS value: 'true' - name: SE_NODE_MAX_SESSIONS value: '4' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' nodeMaxSessions: 4 unsafeSsl: 'true' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL graphql-username: base64 encoded value of GraphQL Username graphql-password: base64 encoded value of GraphQL Password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url - parameter: username name: selenium-grid-secret key: graphql-username - parameter: password name: selenium-grid-secret key: graphql-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.18/scalers/solace-pub-sub-dm.md ================================================ +++ title = "Solace PubSub+ Event Broker - Direct Messaging" availability = "2.18+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker - Direct Messaging" go_file = "solace_dm_scaler" +++ ### Trigger Specification This specification describes the `solace-direct-messaging` trigger that scales based on a Solace PubSub+ Event Broker direct messaging rates for all the clients in a message vpn that matches a common client name prefix. > 💡 **Note:** This trigger is for **Direct messaging** only, it provides the ability to scale the number of client instances automatically based upon transient metrics for shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length), all this metrics exists as long as the clients are connected. If you need to use **Guaranteed messaging** (Solace PubSub+ Event Broker queue) you should use the `solace-event-queue` trigger. ```yaml triggers: - type: solace-direct-messaging metricType: Value metadata: solaceSempBaseURL: "https://solace_broker1:943,https://solace_broker2:943" messageVpn: "message-vpn" clientNamePattern: "client-name-pattern" unsafeSSL: "true" queuedMessagesFactor: '3' aggregatedClientTxMsgRateTarget: '600' aggregatedClientTxByteRateTarget: '0' aggregatedClientAverageTxByteRateTarget: '0' aggregatedClientAverageTxMsgRateTarget: '0' usernameFromEnv: 'ENV_VAR_USER' passwordFromEnv: 'ENV_VAR_PWD' authenticationRef: name: trigger-authentication-ref ``` **Parameter list:** - `solaceSempBaseURL` - Comma separated list of Solace SEMP Endpoint in format: `://:`. (Required) - `messageVpn` - Message VPN hosted on the Solace broker from which the metrics will be collected. (Required) - `clientNamePattern` - Client name pattern that will be used to identify the clients that are consuming from a shared subscription. (Required). It will be used to match all the client names that match the expression: **' \*client-name-pattern\* '** - `unsafeSSL` - Flag to enable unsafe host urls (self signed certificates). (Default: `false`, Optional) - `queuedMessagesFactor` - Flag to to increase weight on queued messages (D-1) and scale faster to avoid discarding messages. (Default: `3`, Optional) - `aggregatedClientTxMsgRateTarget` - Target number messages per second the clients in the shared subscription are expected to consume, if the actual aggregated messages per second number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientTxByteRateTarget` - Target number bytes per second the clients in the shared subscription are expected to consume, if the actual aggregated bytes per second number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientAverageTxByteRateTarget` - Target average number messages per minute the clients in the shared subscription are expected to consume, if the actual aggregated messages per minute number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientAverageTxMsgRateTarget` - Target average number bytes per minute the clients in the shared subscription are expected to consume, if the actual aggregated bytes per minute number is greater the number of replicas will be increased. (Default: `0`, Optional) - `usernameFromEnv` - Environment variable set with SEMP user account. (Optional) - `passwordFromEnv` - Environment variable set with password for the user account. (Optional) **Parameter Requirements:** - Parameters resolving the target host and shared subscription are all **required:** `solaceSempBaseURL`, `messageVpn`, `clientNamePattern` - **At least** one of `aggregatedClientTxMsgRateTarget`, `aggregatedClientTxByteRateTarget`, `aggregatedClientAverageTxByteRateTarget` or `aggregatedClientAverageTxMsgRateTarget` is **required**. If more than one target values are present, calculation is done for each metric and the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) For more details please see [Horizontal Pod Autoscaling - Algorithm details](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) The `solace-direct-messaging` Scaler polls the Solace SEMP REST API to get transient metrics from connected clients. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the trigger to function. These values can be set in several different ways: - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 3 cooldownPeriod: 60 #Always > 0 because is direct messaging! minReplicaCount: 1 maxReplicaCount: 20 advanced: restoreToOriginalReplicaCount: true horizontalPodAutoscalerConfig: behavior: scaleDown: #The stabilization window is used to restrict the flapping of replica count when the metrics used for scaling keep fluctuating. #The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale. #All desired states from the past 1 minutes (60secs) will be considered stabilizationWindowSeconds: 60 #Policy (Pods) allows at most 1 replicas to be scaled down in 10 seconds. policies: - type: Pods value: 1 #Indicates the length of time in the past for which the policy must hold true periodSeconds: 10 scaleUp: stabilizationWindowSeconds: 0 #Policy (Pods) allows at most 3 replicas to be scaled up in 3 seconds. policies: - type: Pods value: 5 periodSeconds: 3 selectPolicy: Max triggers: - type: solace-direct-messaging #we don’t want to take the average of the given metric across all replicas, just the value metricType: Value metadata: solaceSempBaseURL: "https://broker1.messaging.solace.cloud:943,https://broker2.messaging.solace.cloud:943" messageVpn: "consumer_vpn" #all the clients that match this client name pattern will be considered for metric gathering clientNamePattern: "direct-messaging-simple" #to be able to use self signed certs unsafeSSL: "false" #to increase weight on queued messages and scale faster #if there are messages queued means we are behind queuedMessagesFactor: '3' #Metrics aggregatedClientTxMsgRateTarget: '600' aggregatedClientTxByteRateTarget: '0' aggregatedClientAverageTxByteRateTarget: '0' aggregatedClientAverageTxMsgRateTarget: '0' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.18/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. **Note:** This trigger is for **Guaranteed messaging** (Solace PubSub+ Event Broker queue) only, it provides the ability to scale the number of client instances automatically based upon metrics for a Solace PubSub+ Event Broker queue. If you need to use **Direct messaging**, shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length) you should use the `solace-direct-messaging` trigger. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint comma-separated host list in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **solaceSempBaseURL** can contain either a single URL or a comma-separated list of URLs. If multiple URLs are provided, the scaler will iterate over the list until it is both able to connect the broker successfully AND the broker's messageVpn is in the **UP** state. All brokers in the list will share the same authentication configuration. This feature was primarily added to support Solace's Disaster Recovery Replication feature. - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.18/scalers/solarwinds.md ================================================ +++ title = "SolarWinds" availability = "v2.18+" maintainer = "Community" description = "Scale applications based on metrics from SolarWinds." go_file = "solarwinds_scaler" +++ ### Trigger Specification This specification describes the `solarwinds` trigger that scales based on metrics from SolarWinds. ```yaml triggers: - type: solarwinds metadata: host: https://api.na-01.cloud.solarwinds.com targetValue: "1" activationValue: "3" metricName: "k8s.pod.cpu.usage.seconds.rate" aggregation: "AVG" intervalS: "60" filter: "k8s.deployment.name:my-deployment" ``` **Parameter list:** - `host` - The SolarWinds API endpoint. (Example: `https://api.na-01.cloud.solarwinds.com`) - `targetValue` - Value to reach to start scaling. (This value can be an integer or float) - `activationValue` - Target value for activating the scaler. (Optional, Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds)) - `metricName` - The name of the metric to monitor. - `aggregation` - The aggregation method to use. (Values: `COUNT`, `MIN`, `MAX`, `AVG`, `SUM`, `LAST`) - `intervalS` - The interval in seconds for the metric collection. - `filter` - The filter to apply to the metric data. (Optional, Examples below) - `key1:value1 key2:value2` - Search using key values pairs with a delimiting space for an implicit AND - `key:[value1,value2]` - Search using IN operator (key equals value1 or value2) - `key:~value` - Search using CONTAINS operator - `key>value1 key”, “<“, “<=”, “>=”) (key between value1 and value2) - `NOT key:""` - Search using NOT operator and EMPTY value (key is not empty) - `entities(attribute:value)` - search using attributes of entities related to the metric data (metric values associated with entity having attribute equals value) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing the necessary credentials. **Credential based authentication:** - `apiToken` - The API token for accessing SolarWinds Observability. See [doc](https://documentation.solarwinds.com/en/success_center/observability/content/settings/api-tokens.htm) for more information. ### Example Here is an example of a SolarWinds Scaler with authentication: ```yaml apiVersion: v1 kind: Secret metadata: name: solarwinds-secret namespace: default data: apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solarwinds-auth namespace: default spec: secretTargetRef: - parameter: apiToken name: solarwinds-secret key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solarwinds-scaledobject namespace: default spec: scaleTargetRef: name: nginx pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 2 triggers: - type: solarwinds authenticationRef: name: solarwinds-auth metadata: host: https://api.na-01.cloud.solarwinds.com targetValue: "3" activationValue: "3" metricName: "k8s.pod.cpu.usage.seconds.rate" aggregation: "AVG" intervalS: "60" filter: "k8s.deployment.name:my-deployment" ``` ================================================ FILE: content/docs/2.18/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.18/scalers/splunk-observability.md ================================================ +++ title = "Splunk Observability" availability = "v2.18+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk Observability Cloud metrics." go_file = "splunk_observability_scaler" +++ ### Trigger Specification This specification describes the `splunk-observability` trigger that scales based on the result of a metric series queried from the Splunk Observability Cloud platform with a [SignalFlow query](https://dev.splunk.com/observability/docs/signalflow/). ```yaml triggers: - type: splunk-observability metadata: # Required: SignalFlow query to retrieve the desired metric time series query: "data('demo.trans.latency').max().publish()" # Required: Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds duration: "10" # Required: Threshold to reach to start scaling targetValue: "400.1" # Required: Target value for activating the scaler activationTargetValue: "1.1" # Required: Specifies how the Metrics Time Series should be processed, options are "min" (minimum value), "max" (maximum value), and "avg" (average value) queryAggregator: "avg" ``` **Parameter list:** - `query` - SignalFlow query for querying the desired metrics. - `duration` - Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds. - `targetValue` - Threshold to reach to start scaling. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `queryAggregator` - When querying metrics from Splunk Observability Cloud, initially a Metric Time Series (MTS) is returned, a list consisting of several datapoints. The 'queryAggregator' specifies how this series of metrics should be "rolled up". Valid values for this field are "avg", which returns the average, "min", which returns the minimum of the metrics in the series, and "max", which returns the maximum value. **Parameter list:** - `accessToken` - Splunk Observability Cloud Access Token. - `realm` - Splunk Observability Cloud Realm. ## Configuration Example The following example shows how to scale a simple NGINX employment with the help of KEDA and the Splunk Observability Cloud scaler: #### Simple NGINX employment ```yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ``` #### Authentication ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-secrets data: accessToken: realm: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-splunk-secret spec: secretTargetRef: - parameter: accessToken name: splunk-secrets key: accessToken - parameter: realm name: splunk-secrets key: realm ``` #### KEDA Scaler ```yaml --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: splunk-observability metricType: Value metadata: query: "data('demo.trans.count', filter=filter('demo_host', 'server6'), rollup='rate').sum(by=['demo_host']).publish()" duration: "10" queryValue: "400.1" activationQueryValue: "1.1" queryAggregator: "max" # 'min', 'max', or 'avg' authenticationRef: name: keda-trigger-auth-splunk-secret ``` ================================================ FILE: content/docs/2.18/scalers/splunk.md ================================================ +++ title = "Splunk" availability = "v2.15+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk saved search results." go_file = "splunk_scaler" +++ ### Trigger Specification This specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches). The trigger always requires the following information: ```yaml triggers: - type: splunk metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "1" activationValue: "10" savedSearchName: my-saved-search-name valueField: count ``` **Parameter list:** - `host` - Search API host and port. Example: `https://localhost:8089`. - `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `"true"`, `"false"`, Default: `"false"`, Optional) - `targetValue` - Value to reach to start scaling (This value can be a integer or float). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `savedSearchName` - Name of saved search that returns metric data for scaling. - `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`. ### Authentication Parameters You can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication. > **Note:** > > `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API. **Parameter list:** - `username` - Splunk username authorized to access the search API. - `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`. - `password` - Password for supplied `username`. Conflicts with `apiToken`. The user will need access to the saved search. ### Examples ### Username/password ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### API Token ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # admin apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: apiToken name: splunk-creds key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### Full example using Splunk deployment ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: splunkconf data: default.yml: | splunk: conf: - key: savedsearches value: directory: /opt/splunk/etc/users/admin/search/local content: my-saved-search-name: action.email.useNSSubject: 1 action.webhook.enable_allowlist: 0 alert.track: 0 cron_schedule: '*/1 * * * *' dispatch.earliest_time: -15m dispatch.latest_time: now display.general.type: statistics display.page.search.tab: statistics display.visualizations.show: 0 enableSched: 1 request.ui_dispatch_app: search request.ui_dispatch_view: search search: index=_internal | tail | stats count --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: v1 kind: Service metadata: name: splunk spec: ports: - port: 8000 targetPort: web name: web-svc - port: 8089 targetPort: 8089 name: api-svc selector: app: splunk --- apiVersion: apps/v1 kind: Deployment metadata: name: splunk namespace: default spec: replicas: 1 selector: matchLabels: app: splunk template: metadata: labels: app: splunk spec: containers: - name: splunk image: splunk/splunk:9.2 ports: - containerPort: 8000 name: web - containerPort: 8089 name: api env: - name: SPLUNK_START_ARGS value: --accept-license - name: SPLUNK_PASSWORD value: password volumeMounts: - name: splunkconf-volume mountPath: /tmp/defaults volumes: - name: splunkconf-volume configMap: name: splunkconf --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8080 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 unsafeSsl: "true" targetValue: "5" activationValue: "5" savedSearchName: my-saved-search-name valueField: count ``` ================================================ FILE: content/docs/2.18/scalers/sumologic.md ================================================ +++ title = "Sumo Logic" availability = "v2.18+" maintainer = "Community" category = "Monitoring & Analytics" description = "Scale applications based on Sumo Logic logs searches and metrics queries." go_file = "sumologic_scaler" +++ ## Trigger Specification This specification describes the `sumologic` trigger that scales based on Sumo Logic logs searches and metrics queries. The scaler supports three different query types: - **`logs`** - Scale based on Sumo Logic logs query results - **`metrics`** - Scale based on single Sumo Logic metrics query results - **`metrics` (multi-query)** - Scale based on multiple combined Sumo Logic metrics queries Here are examples of the different trigger configurations: **Logs Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" # Sumo Logic API endpoint queryType: "logs" # Type must be "logs" query: "_view=my_view | count" # Your Sumo Logic logs query resultField: "_count" # Field to extract value from timerange: "15m" # Lookback window timezone: "Asia/Kolkata" # Timezone (e.g., Asia/Kolkata) queryAggregator: "Max" # Aggregation method: Latest, Avg, Sum, Count, Min, Max threshold: "1000" # Threshold for scaling authenticationRef: name: keda-trigger-auth-sumologic ``` **Single Metrics Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "metrics" query: "metric=cpu.usage | avg" quantization: "15s" rollup: "Max" timerange: "15m" timezone: "Asia/Kolkata" queryAggregator: "Max" threshold: "50" maxRetries: "3" # Optional: Maximum retry attempts authenticationRef: name: keda-trigger-auth-sumologic ``` **Multi-Metrics Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "metrics" query.A: "metric=requests_total | rate" query.B: "metric=request_capacity" query.C: "(#A / #B) * 100 along service" resultQueryRowID: "C" # Which query result to extract quantization: "15s" rollup: "Max" timerange: "15m" timezone: "Asia/Kolkata" queryAggregator: "Max" threshold: "75" authenticationRef: name: keda-trigger-auth-sumologic ``` **Parameter list:** **Common Parameters:** - `host` - Sumo Logic API endpoint URL (Based on your Geo). - `queryType` - Type of query. (Values: `logs`, `metrics`) - `query` - Sumo Logic query (for single queries). - `timerange` - Time range to evaluate the query. - `timezone` - Timezone for query execution. (Default: `UTC`, Optional) - `queryAggregator` - Aggregation method. (Values: `Latest`, `Avg`, `Sum`, `Count`, `Min`, `Max`, Default: `Avg`, Optional) - `threshold` - Target value for scaling. - `maxRetries` - Maximum number of retry attempts for API requests. (Default: `3`, Optional) **Logs Query Specific Parameters:** - `resultField` - Field from query results to extract the scaling metric. (Required when `queryType` is `logs`) - `logsPollingInterval` - Polling interval for log search job. (Default: `1s`, Optional) **Metrics Query Specific Parameters:** - `quantization` - Granularity of data points. (Required when `queryType` is `metrics`) - `rollup` - Metrics rollup type. (Values: `Avg`, `Sum`, `Min`, `Max`, `Count`, Default: `Avg`, Optional) **Multi-Metrics Query Specific Parameters:** - `query.A`, `query.B`, `query.C` etc - Multi-stage queries, where later queries can refer to earlier ones. (Required for multi-metrics queries) - `resultQueryRowID` - Which final query (`A`, `B`, `C`, etc.) to use for scaling. (Required for multi-metrics queries) ## Authentication Parameters You must configure a `TriggerAuthentication` resource to authenticate with Sumo Logic. **Prerequisites:** - A Sumo Logic Access ID and Access Key Authentication is handled through a Kubernetes `Secret` combined with a `TriggerAuthentication`: ```yaml apiVersion: v1 kind: Secret metadata: name: sumologic-auth-secret data: accessID: accessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-sumologic spec: secretTargetRef: - parameter: accessID name: sumologic-auth-secret key: accessID - parameter: accessKey name: sumologic-auth-secret key: accessKey ``` ### Example Here is a complete example that demonstrates autoscaling based on Sumo Logic logs query: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: sumologic-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "logs" query: "_view=error_logs | count" resultField: "_count" timerange: "5m" threshold: "100" authenticationRef: name: keda-trigger-auth-sumologic ``` ### Notes - `pollingInterval` controls how often KEDA polls Sumo Logic. - `cooldownPeriod` controls how long KEDA waits before scaling down. - `MetricType:` The scaler supports both `AverageValue` and `Value` metric types. - Ensure that the Sumo Logic user has **appropriate access** to the queries being executed. ================================================ FILE: content/docs/2.18/scalers/temporal.md ================================================ +++ title = "Temporal" availability = "v2.17+" maintainer = "Community" description = "Scale applications based on Temporal task queue." go_file = "temporal_scaler" +++ ### Trigger Specification This specification describes the `temporal` trigger that scales based on a Temporal task queue. ```yaml triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 queueTypes: workflow # optional buildId: 1.0.0 # optional selectAllActive: "false" # optional selectUnversioned: "false" # optional minConnectTimeout: "5" # optional unsafeSsl: "false" # optional tlsServerName: "custom-tls-servername" # optional ``` **Parameter list:** - `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `:`. (Required) - `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional) - `namespace` - The namespace of the temporal service. (Default:`default`, Optional) - `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional) - `taskQueue` - This parameter specifies the task queue name. (Required) - `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional) - `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional) - `selectAllActive` - Include all active versions (Default:`false`, Optional) - `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional) - `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional) - `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional) - `tlsServerName` - The custom tls server name (Optional) > 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero. This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog. Consequently, scaling to zero could result in undesirable behavior, such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA). By fine-tuning the configurations, you can prevent premature scaling to zero, ensuring that resources remain available for in-flight tasks or workloads with minimal throughput. **Authentication Parameters:** Temporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication: - `apiKey` - API key for authentication with temporal cloud. (Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: temporal-secret namespace: default type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-temporal namespace: default spec: secretTargetRef: - parameter: apiKey name: temporal-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject namespace: default spec: scaleTargetRef: name: workload-scaledobject pollingInterval: 5 cooldownPeriod: 10 minReplicaCount: 0 maxReplicaCount: 5 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 10 triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 authenticationRef: name: keda-trigger-auth-temporal ``` ================================================ FILE: content/docs/2.18/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.18/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.19/_index.md ================================================ +++ title = "Getting Started" description = "How you can start with KEDA as new user" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation bar on the left to learn more about KEDA's architecture and how to deploy and use KEDA. ## Where to go What is your involvement with KEDA? | Role | Documentation | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | User | This documentation is for users who want to deploy KEDA to scale Kubernetes. | | Core Contributor | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda). | | Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). | | Other Contributor | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers. | ================================================ FILE: content/docs/2.19/addons/_index.md ================================================ +++ title = "Add-ons" weight = 3 +++ Add-ons extend KEDA with support for specific use cases beyond the built-in scalers. ## HTTP Add-on The [HTTP Add-on](/http-add-on/latest/) enables autoscaling of HTTP-based workloads. It intercepts incoming HTTP requests and scales the target workload based on request volume. ================================================ FILE: content/docs/2.19/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.19/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.19/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optionqal ``` ================================================ FILE: content/docs/2.19/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. **Regional STS endpoints** - If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace. - If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses). ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: namespace: annotations: eks.amazonaws.com/role-arn: # Required for regional STS endpoints (e.g. eu-west-1) eks.amazonaws.com/sts-regional-endpoints: "true" ``` ### When do you need regional STS endpoints? By default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`). Some regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`). If you see errors like: ``` AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity ``` while your IAM trust policy looks correct, you likely need to enable regional endpoints with: ```yaml annotations: eks.amazonaws.com/sts-regional-endpoints: "true" ``` 👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure Attach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` ================================================ FILE: content/docs/2.19/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.19/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.19/authentication-providers/bound-service-account-token.md ================================================ +++ title = "Bound service account token" +++ You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ## Permissions for KEDA to request service account tokens By default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster. To allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource. Here's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator namespace: my-namespace # Replace with the namespace of the service account rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - my-service-account # Replace with the name of the service account --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding namespace: my-namespace # Replace with the namespace of the service account roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator subjects: - kind: ServiceAccount name: keda-operator namespace: keda # Assuming the keda-operator service account is in the keda namespace ``` After applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API. ### Usage in keda-charts If you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example: ```yaml # values.yaml permissions: operator: restrict: serviceAccountTokenCreationRoles: - name: myServiceAccount namespace: myServiceAccountNamespace ``` This will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator-myServiceAccount namespace: myServiceAccountNamespace rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - myServiceAccount --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding-myServiceAccount namespace: myServiceAccountNamespace roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator-myServiceAccount subjects: - kind: ServiceAccount name: keda-operator namespace: keda ``` ================================================ FILE: content/docs/2.19/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.19/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.19/authentication-providers/file-path.md ================================================ +++ title = "File path" +++ You can read authentication parameters from files mounted in the KEDA operator pod using the `filePath` option. This feature requires the KEDA operator to be configured with a root path for file access. ## Security Constraints The `filePath` feature has important security constraints: - **Requires root path configuration** - The KEDA operator must be started with `--filepath-auth-root-path` to define the allowed directory - **Path validation** - All file paths are validated to ensure they resolve within the configured root path, preventing access to sensitive system files like service account tokens - **Relative paths** - The `filePath` in `ClusterTriggerAuthentication` is treated as a relative path under the configured root path ## Operator Configuration The KEDA operator requires a command-line argument to enable file-based authentication: ```bash --filepath-auth-root-path=/path/to/allowed/files ``` This path should point to a directory where credential files are mounted. The operator will only read files from within this directory. ## Example First, ensure the KEDA operator has the root path configured. Then create a `ClusterTriggerAuthentication` referencing files: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: file-based-auth spec: filePath: - parameter: apiKey # Required - Defined by the scale trigger path: credentials/api-key # Required - Path relative to filepath-auth-root-path ``` **Assumptions:** - The path is relative to the `--filepath-auth-root-path` configured for the KEDA operator - The credential file exists at `{filepath-auth-root-path}/credentials/api-key` - The file contains the raw credential value (not JSON encoded) - The file path should match the actual file name, including any extension if present (e.g., `credentials/api-key.txt` if the file is named `api-key.txt`) ================================================ FILE: content/docs/2.19/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.19/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.19/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method. There's multiple methods for authentication; For kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) or provide the serviceAccountName that can authenticate to kubernetes in the namespace of the ScaledObject/ScaledJob resource (usually `default`). If using serviceAccountName make sure to grant KEDA Operator `create serviceaccounts/token` permissions. This is set in the helm chart via `permissions.operator.restrict.allowAllServiceAccountTokenCreation=true` For token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. Authenticate to vault via a supplied token serviceAccount: {path-to-service-account-file} # Optional. Authenticate to vault via JWT token in keda operator pod serviceAccountName: {service-account-name-for-auth} # Optional. Requires serviceaccounts/token create permissions. Authenticate to vault via JWT token from service account in ScaledObject/ScaledJob's namespace secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.19/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.19/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests. It’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup. ## How KEDA works KEDA monitors external event sources and adjusts your app’s resources based on the demand. Its main components work together to make this possible: * **KEDA Operator** keeps track of event sources and changes the number of app instances up or down, depending on the demand. * **Metrics Server** provides external metrics to Kubernetes’ HPA so it can make scaling decisions. * **Scalers** connect to event sources like message queues or databases, pulling data on current usage or load. * **Custom Resource Definitions (CRDs)** define how your apps should scale based on triggers like queue length or API request rates. In simple terms, KEDA listens to what’s happening outside Kubernetes, fetches the data it needs, and scales your apps accordingly. It’s efficient and integrates well with Kubernetes to handle scaling dynamically. ## KEDA Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch.png) External events, like an increase in queue messages, trigger the **ScaledObject**, which sets the scaling rules. The **Controller** handles the scaling, while the **Metrics Adapter** sends data to the HPA for real-time scaling decisions. **Admission Webhooks** ensure your configuration is correct and won’t cause problems. This setup lets Kubernetes adjust resources automatically based on what’s happening outside, keeping things efficient and responsive. ## KEDA Custom Resources (CRDs) KEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior: * **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works. * **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics. * **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials. These CRDs give you control over scaling while keeping your apps secure and responsive to demand. ## Scaling Deployments, StatefulSets, and Custom Resources KEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs. ### Scaling Deployments and StatefulSets With KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand. Deployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand. ### Scaling Custom Resources KEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically. ### Scaling Jobs KEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed. ### Authentication KEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe. ### External Scalers KEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly. ### Consuming Raw Scaler Metrics Externally KEDA also allows consuming the internal metrics (coming from internal or external scalers) to interested 3rd parties. This feature is exposed using gRPC server stream API and needs to be first enabled by setting `RAW_METRICS_GRPC_PROTOCOL` to "`enabled`". Then one can subscribe to a metric identified by ScaledObject/ScaledJob name, namespace and trigger name using any gRPC client (example with [grpcurl](https://github.com/kedacore/keda/pull/7093#issuecomment-3333530716)). You can control when raw metrics are sent using the `RAW_METRICS_MODE` environment variable: * `all` or `""` (empty): Sends all raw metrics, both when the metrics server requests them (HPA) and during the regular polling interval of each ScaledObject or ScaledJob. This is the default behavior. * `hpa`: Sends raw metrics only when the Kubernetes metrics server explicitly requests metrics for a ScaledObject. This means metrics are sent in response to HPA queries, not on a regular schedule. * `pollinginterval`: Sends raw metrics only during the polling interval of each ScaledObject or ScaledJob. In this mode, metrics are pushed out at each polling cycle, regardless of HPA requests. * Any unknown value will default to the `all` mode. ### Admission Webhooks KEDA uses admission webhooks to validate your scaling setup. They ensure your configuration is correct, like preventing multiple ScaledObjects from targeting the same app. This reduces errors and makes scaling smoother. ================================================ FILE: content/docs/2.19/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.19/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject filePath: # Optional. Define only for ClusterTriggerAuthentication; not supported for TriggerAuthentication. - parameter: {scaledObject-parameter-name} # Required. path: {relative-path-to-file} # Required. Relative to --filepath-auth-root-path. hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### File(s) > **Note:** This feature requires the KEDA operator to be configured with `--filepath-auth-root-path`. You can read authentication parameters from files mounted in the KEDA operator pod. This is useful when credentials are provided via init containers or sidecars that write to a shared volume. The `filePath` option is only available for `ClusterTriggerAuthentication`, not for namespaced `TriggerAuthentication`. ```yaml filePath: # Optional. - parameter: apiKey # Required - Defined by the scale trigger path: credentials/api-key # Required - Path relative to filepath-auth-root-path ``` **Security constraints:** - The path is validated to ensure it resolves within the configured `--filepath-auth-root-path` - Access to sensitive paths like `/var/run/secrets/kubernetes.io/serviceaccount/` is blocked - Only `ClusterTriggerAuthentication` can use this authentication method **Assumptions:** - The KEDA operator must be started with `--filepath-auth-root-path=/path/to/allowed/files` - The credential file exists at `{filepath-auth-root-path}/{path}` - The file contains the raw credential value ### Bound service account token(s) You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.19/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.19/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ This page describes the deployment scaling behavior of KEDA. # Specification See the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below. # Scaling objects ## Scaling Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## Scaling Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). # Features ## Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval. Enabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ## Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`. Additionally, we provide the ability to temporarily pause scale in on a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/paused-scale-in: "true" ``` When the annotation is set, KEDA will update the generated HPA to disable scale in (via setting the HPA's Scale Down Select Policy to Disabled) and if the service has scale to zero configured, will block scale to zero. When the annotation is unset, the scale down behavior on the HPA will be restored to its original configuration and, if configured, scale to zero will be unblocked. Conversely, we provide the ability to temporarily pause scale out on a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/paused-scale-out: "true" ``` When the annotation is set, KEDA will update the generated HPA to disable scale out (via setting the HPA's Scale Up Select Policy to Disabled) and if the service has scale to zero configured, will block scale from zero. When the annotation is unset, the scale up behavior on the HPA will be restored to its original configuration and, if configured, scale up from zero will be unblocked. If you want disable scaling in both directions, we recommend you use the `autoscaling.keda.sh/paused` as that will stop the scale loop and paused queries against the ScaledObject's configured scaler. ## Scaling Modifiers **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ## Activating and Scaling thresholds KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Forcing Activation We provide the ability to temporarily force the activation of a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/force-activation: "true" ``` When the annotation is set, KEDA will treat all configured scalers as active. If the scalers were previously not active, KEDA will scale the service up from 0. When the annotation is subsequently unset, the state of the scaler activation will revert to being computed from the state of the scaler metrics. ## Transferring ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disabling validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ### Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. #### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. #### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](./scaling-jobs). ## Excluding labels from being propagated to the HPA You can exclude specific labels from being propagated to the generated HPA object by using the `scaledobject.keda.sh/hpa-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded. ```yaml metadata: annotations: scaledobject.keda.sh/hpa-excluded-labels: "foo.bar/environment,foo.bar/version" labels: team: backend foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5 foo.bar/version: "1" ================================================ FILE: content/docs/2.19/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ This page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below. # Overview As an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` # Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` To reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`. ```yaml metadata: annotations: autoscaling.keda.sh/paused: false ``` ## Example An example configuration for autoscaling jobs using a RabbitMQ scaler is given below. ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` # Excluding labels from being propagated to the Job You can exclude specific labels from being propagated to the generated Job object by using the `scaledjob.keda.sh/job-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded. ```yaml metadata: annotations: scaledjob.keda.sh/job-excluded-labels: "foo.bar/environment,foo.bar/version" labels: team: backend foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5 foo.bar/version: "1" ================================================ FILE: content/docs/2.19/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.19/deploy.md ================================================ +++ title = "Deploying KEDA" +++ KEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization. Using **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster. Each method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment. > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.30 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Prerequisites To deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features. If you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease. ### Installing 1. To deploy KEDA using Helm, first add the official KEDA Helm repository: ```sh helm repo add kedacore https://kedacore.github.io/charts helm repo update ``` 2. Install `keda` by running: **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods: ```sh kubectl get pods -n keda ``` To deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps: 1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version. 2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions: ```sh kubectl apply -f keda-2.xx.x-crds.yaml ``` Replace `2.xx.x` with the specific version number you downloaded. By deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process. > 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues. Deploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments. ### Uninstalling To uninstall KEDA, use the following Helm command: ```sh helm uninstall keda –namespace keda ``` This command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run: ```sh kubectl delete namespace keda ``` Uninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version. You can remove finalizers with the following command: ```sh kubectl patch scaledobject -p '{"metadata":{"finalizers":null}}' --type=merge kubectl patch scaledjob -p '{"metadata":{"finalizers":null}}' --type=merge ``` Replace \<*resource-name*\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster. ## Deploying with Operator Hub {#operatorhub} ### Prerequisites Before deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access. If you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub. ### Installing To deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed. Search for "KEDA" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace. 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) Using Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment. > 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository: > > [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator) > > This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments. > > For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful: > > \- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator. > > \- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster. > > \- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project. ### Uninstalling To uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster. If you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks. ## Deploying KEDA using the YAML files {#yaml} ### Prerequisites Before deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster. ### Installing Once the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command: ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0-core.yaml ``` Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.19.0.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.19.0-core.yaml ``` The `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740). > 💡 **NOTE:** If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally: > > ```sh > git clone https://github.com/kedacore/keda && cd keda > > VERSION=2.19.0 make deploy > ``` > > This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization. After applying the YAML, verify the deployment by checking the KEDA namespace: ```sh kubectl get pods -n keda ``` Deploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates. ### Uninstalling If you installed KEDA using the released YAML files, you can uninstall it by running the following commands: ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0-core.yaml ``` If you downloaded the files locally, uninstall with: ```sh # Including admission webhooks kubectl delete -f keda-2.19.0.yaml # Without admission webhooks kubectl delete -f keda-2.19.0-core.yaml ``` For users who cloned the KEDA GitHub repository, navigate to the cloned directory and use: ```sh VERSION=2.19.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Prerequisites Before deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`). Additionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons: * **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration. * **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation. ### Installing To install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on. 1. Enable Helm and DNS Add-ons (if not already enabled): ```sh microk8s enable dns helm3use ``` 2. Add the KEDA Helm Repository: ```sh microk8s helm3 repo add kedacore https://kedacore.github.io/charts microk8s helm3 repo update ``` 3. Install KEDA Using Helm. Deploy KEDA into your MicroK8s cluster by running: ```sh microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace ``` 4. Verify the Installation. Check that KEDA is running by listing the pods in the keda namespace: ```sh microk8s kubectl get pods -n keda ``` This approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development. ### Uninstalling To uninstall KEDA from your MicroK8s environment, disable the KEDA add-on: ```sh microk8s disable keda ``` This command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation. If you deployed KEDA using Helm, uninstall it with: ```sh microk8s helm3 uninstall keda --namespace keda ``` After running these commands, KEDA will be fully removed from your MicroK8s setup. ## Getting Started with KEDA: A Simple Example To help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This "Hello KEDA" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality. Before starting, ensure you have the following: * **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service. * **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster. * **KEDA Installed**: KEDA should be installed in your cluster. ### Step 1: Deploy a Sample Application We'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server. 1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: http-app spec: replicas: 1 selector: matchLabels: app: http-app template: metadata: labels: app: http-app spec: containers: - name: http-app image: hashicorp/http-echo args: - "-text=Hello, KEDA!" ports: - containerPort: 5678 ``` 2. **Apply the Deployment**: Run the following command to create the deployment: ```sh kubectl apply -f deployment.yaml ``` ### Step 2: Expose the Application To access the application, we'll create a Service. 1. **Create a Service Manifest**: Save the following YAML as `service.yaml`: ```yaml apiVersion: v1 kind: Service metadata: name: http-app-service spec: selector: app: http-app ports: - protocol: TCP port: 80 targetPort: 5678 type: LoadBalancer ``` 2. **Apply the Service**: Run the following command to create the service: ```sh kubectl apply -f service.yaml ``` 3. **Retrieve the External IP**: After a few moments, retrieve the external IP address: ```sh kubectl get service http-app-service ``` ### Step 3: Create a ScaledObject We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. 1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-app-scaledobject spec: scaleTargetRef: name: http-app minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: prometheus metadata: serverAddress: http://prometheus-server.default.svc.cluster.local:9090 threshold: '5' query: sum(rate(http_requests_total[1m])) ``` > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed. 2. **Apply the ScaledObject**: Run the following command to create the ScaledObject: ```sh kubectl apply -f scaledobject.yaml ``` ### Step 4: Test the Scaling Behavior We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. To observe KEDA's scaling in action: 1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP: ```sh hey -z 1m -c 10 http:// ``` Replace `` with the external IP address obtained earlier. 2. **Monitor Scaling:** Run the following command to watch the scaling behavior: ```sh kubectl get pods -w ``` You should see the number of pods increase as the load increases and decrease when the load subsides. ### Cleanup After completing the exercise, clean up the resources: ```sh kubectl delete -f scaledobject.yaml kubectl delete -f service.yaml kubectl delete -f deployment.yaml ``` This example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events. ================================================ FILE: content/docs/2.19/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.19/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.19/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.19/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). > Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.19/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.19/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance and requirements for operating KEDA" weight = 1 +++ We provide guidance and requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](../reference/events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.19/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ### Cache Miss with Fallback to Direct Client for ScaledObject When validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`: ``` --cache-miss-to-direct-client=true ``` This will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API. ## Custom Validations using Kubernetes ValidatingAdmissionPolicy > ⚠️ FEATURE STATE: Kubernetes v1.30 [stable] Kubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). Here is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10): ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-keda-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["keda.sh"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["scaledobjects"] validations: - expression: "object.spec.maxReplicaCount <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-keda-replicas-binding.example.com" spec: policyName: "limit-keda-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` Since KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas: ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-apps-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments", "replicasets"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-hpa-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["autoscaling"] apiVersions: ["v2"] operations: ["CREATE", "UPDATE"] resources: ["horizontalpodautoscalers"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-apps-replicas-binding.example.com" spec: policyName: "limit-apps-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-hpa-replicas-binding.example.com" spec: policyName: "limit-hpa-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` ================================================ FILE: content/docs/2.19/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 When a CloudEventSource resource is created, KEDA continues to emit Kubernetes Events and will additionally emit CloudEvents for the supported event types listed in this document. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | | `keda.scaledobject.removed.v1` | When a ScaledObject is deleted | | `keda.scaledobject.paused.v1` | When a ScaledObject is paused | | `keda.scaledobject.unpaused.v1` | When a ScaledObject is unpaused | | `keda.scaledjob.ready.v1` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledjob.failed.v1` | If the check validation for a ScaledJob fails | | `keda.scaledjob.removed.v1` | When a ScaledJob is deleted | | `keda.scaledjob.paused.v1` | When a ScaledJob is paused | | `keda.scaledjob.unpaused.v1` | When a ScaledJob is unpaused | | `keda.scaledjob.rolloutcleanup.started.v1` | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob | | `keda.scaledjob.rolloutcleanup.completed.v1` | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob | | `keda.scaledjob.rolloutcleanup.failed.v1` | When KEDA fails to delete a Job owned by the previous version of a ScaledJob | | `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created | | `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | | `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted | | `keda.authentication.clustertriggerauthentication.created.v1` | On the first time a ClusterTriggerAuthentication is created | | `keda.authentication.clustertriggerauthentication.updated.v1` | When a ClusterTriggerAuthentication is updated | | `keda.authentication.clustertriggerauthentication.removed.v1` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.19/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.19 | v1.32 - v1.34 | | v2.18 | v1.31 - v1.33 | | v2.17 | v1.30 - v1.32 | | v2.16 | v1.29 - v1.31 | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 on the KEDA operator deployment to your desired timeout in milliseconds. > ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata. ## 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ## Restrict Custom Resources As KEDA supports scaling any workload inside the cluster, there is a non restrictive RBAC rule applied to all the cluster ```yaml - apiGroups: - * resources: - */scale verbs: - get - list - patch - update - watch - apiGroups: - * resources: - * verbs: - get ``` However, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces as well as any workload type accross all the cluster. To limit this permissions, you can review and adapt the RBAC generated by KEDA based on your necessities to only grant those permissions that you intentionally want to grant. > Note: If you are using KEDA's helm chart, you can totally disable Custom Resources via `rbac.enabledCustomScaledRefKinds` or limit the current `*` setting only your needed resources via `rbac.scaledRefKinds`. > It is always recommended to review the final generated role for KEDA components to ensure no broad permissions are assigned if the Helm template was customized. To quickly verify typical cases like blocked access to secrets, any tool used to analyze K8s RBAC can be used (e.g. https://github.com/aquasecurity/kubectl-who-can). ## Logs KEDA uses zap to emit logs. The following flags can be used to configure logging behavior in both the metrics-apiserver and operator: - zap-encoder: Zap log encoding (one of `json` or `console`). Default is `console` - zap-log-level: Zap Level to configure the verbosity of logging. Can be one of `debug`, `info`, `error`, or any integer value > 0 which corresponds to custom debug levels of increasing verbosity". Default is `info`. - zap-time-encoding: Zap time encoding (one of `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano`), Defaults is `rfc3339`. ================================================ FILE: content/docs/2.19/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (external metrics only): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.19/operate/schema.md ================================================ +++ title = "Schema" description = "Specification & generation of KEDA scalers' schema" weight = 100 +++ ## Scaler Schema KEDA provides a separate scaler's schema for third-party usage ([scalers-metadata-schema.yaml](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.yaml)/[scalers-metadata-schema.json](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.json)). The schema file will keep updating according to the scaler's refactor. *Notice: The schema file still lacks some of the scalers. It will be completed once all scalers are refactored to use the new declarative scaler config. ## Specification Here is a the schema of the scalers: ``` kedaVersion: main schemaVersion: 1 scalers: - type: activemq parameters: - name: managementEndpoint type: string optional: true metadataVariableReadable: true - name: destinationName type: string optional: true metadataVariableReadable: true - name: brokerName type: string optional: true metadataVariableReadable: true - name: username type: string metadataVariableReadable: true envVariableReadable: true triggerAuthenticationVariableReadable: true - name: password type: string metadataVariableReadable: true envVariableReadable: true triggerAuthenticationVariableReadable: true - name: corsHeader type: string optional: true metadataVariableReadable: true - name: restAPITemplate type: string optional: true metadataVariableReadable: true - name: targetQueueSize type: string default: "10" metadataVariableReadable: true - name: activationTargetQueueSize type: string default: "0" metadataVariableReadable: true - type: apache-kafka parameters: - name: bootstrapServers ... ``` **Metadata field's property detail:** | Property | Description |--------------|------------ | name | the name of the field | type | type is the variable type of the field | optional | optional is a boolean that indicates if the field is optional | default | default is the default value of the field | allowedValue | allowedValue is a list of allowed values for the field | deprecated | deprecated is a string that indicates if the field is deprecated | deprecatedAnnounce | deprecatedAnnounce is a string that indicates the deprecation message | separator | separator is the symbol that separates the value of the field if the value is a list string | exclusiveSet | exclusiveSet is a list of fields that are exclusive with the field | rangeSeparator | rangeSeparator is the symbol that indicates the range of the field | metadataVariableReadable | metadataVariableReadable is a boolean that indicates if the field can be read from the environment | envVariableReadable | envVariableReadable is a boolean that indicates if the field can be read from the environment | triggerAuthenticationVariableReadable | triggerAuthenticationVariableReadable is a boolean that indicates if the field can be read from the trigger authentication ## Generation There are two ways to generate scaler schemas: 1. Run the GO file in the schema folder directly ``` go run schema/generate_scaler_schema.go parameters: --keda-version string Set the version of current KEDA in schema. (default "1.0") --kubeconfig string Paths to a kubeconfig. Only required if out-of-cluster. --output-file-path string scaler-metadata-schemas.yaml output file path. (default "./") --scalers-builder-file buildScaler The file that exists buildScaler func. (default "../pkg/scaling/scalers_builder.go") --scalers-files-dir string The directory that exists all scalers' files. (default "../pkg/scalers") --specify-scaler string Specify scaler name. ``` 2. Use makefile ``` make generate-scaler-schemas env variables: OUTPUT_FILE_PATH scaler-metadata-schemas.yaml output file path. (default "./") SCALERS_BUILDER_FILE The file that exists buildScaler func. (default "../pkg/scaling/scalers_builder.go") SCALERS_FILES_DIR The directory that exists all scalers' files. (default "../pkg/scalers") ``` SCALERS_BUILDER_FILE ?= "pkg/scaling/scalers_builder.go" SCALERS_FILES_DIR ?= "pkg/scalers" OUTPUT_FILE_PATH ?= "schema/" ================================================ FILE: content/docs/2.19/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). Additionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources. Example use case: - When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources. 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory. Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`. ================================================ FILE: content/docs/2.19/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.19/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectUpdateFailed` | `Warning` | When KEDA fails to update status for a ScaledObject | | `ScaledJobUpdateFailed` | `Warning` | When KEDA fails to update status for a ScaledJob | | `ScaledObjectPaused` | `Normal` | When a ScaledObject is paused | | `ScaledObjectUnpaused` | `Normal` | When a ScaledObject is unpaused | | `ScaledObjectFallbackActivated` | `Normal` | When a ScaledObject fallback becomes active | | `ScaledObjectFallbackDeactivated` | `Normal` | When a ScaledObject fallback becomes inactive | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `ScaledJobPaused` | `Normal` | When a ScaledJob is paused | | `ScaledJobUnpaused` | `Normal` | When a ScaledJob is unpaused | | `ScaledJobPauseFailed` | `Warning` | When KEDA fails to pause a ScaledJob | | `ScaledJobRolloutCleanupStarted` | `Normal` | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob | | `ScaledJobRolloutCleanupCompleted` | `Normal` | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob | | `ScaledJobRolloutCleanupFailed` | `Warning` | When KEDA fails to delete a Job owned by the previous version of a ScaledJob | | `ScaledJobActive` | `Normal` | When a ScaledJob becomes active (triggers are active and scaling is performed) | | `ScaledJobInactive` | `Normal` | When a ScaledJob becomes inactive (triggers are not active and scaling is not performed) | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAMetricSourceFailed` | `Warning` | When a scaler fails as a metric source for custom formula | | `KEDAScalerInfo` | `Normal` | When a Scaler contains deprecated field | | `KEDAScalerInfo` | `Warning` | When a Scaler contains unexpected parameter (disabled by default, enable with `KEDA_CHECK_UNEXPECTED_SCALERS_PARAMS`) | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `KEDAJobCreateFailed` | `Warning` | When KEDA fails to create a Job for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationUpdated` | `Normal` | When a TriggerAuthentication is updated | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationUpdated` | `Normal` | When a ClusterTriggerAuthentication is updated | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.19/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_19" >}} ================================================ FILE: content/docs/2.19/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## gRPC Remote Procedure Calls (gRPC) gRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.19/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). **eager** When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible. For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours. ### pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: rabbitmq metadata: queueName: woker_queue hostFromEnv: RABBITMQ_URL mode: QueueLength value: "1" ``` We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 3 | If we switch to `eager`, the result becomes: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 6 | We can identify the difference in their final states. You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.19/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: {kind-of-behavior} # Optional. Default: "static" advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. When scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N. If you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: "static" # Optional. Default: "static" ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. Fallback is supported for all triggers of both `Value` and `AverageValue` metric types, except CPU & memory triggers. It's also only supported by `ScaledObjects`, not `ScaledJobs`. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula for `AverageValue` metrics: ``` target metric value * fallback replicas ``` For `Value` metrics it's using the formula: ``` target metric value * fallback replicas / current ready replicas ``` These formulas offset the HPA's calculations and will cause it to scale the deployment to the specified number of fallback replicas. ## fallback.behavior The `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used. #### `static` behavior When `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'. #### `currentReplicas` behavior When using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'. #### `currentReplicasIfHigher` behavior When using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'. #### `currentReplicasIfLower` behavior When using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 tolerance: 0.1 # requires Kubernetes v1.33 or newer and feature gate "HPAConfigurableTolerance" ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. #### horizontalPodAutoscalerConfig.behavior tolerance As of Kubernetes v1.34 the `tolerance` field can be specified under the HPA behavior policy `scaleUp` and `scaleDown` sections. The field applies a tolerance thresholds for scaling decisions, allowing you to specify different behavior for scale-up and scale-down operations. This field was in alpha release under Kubernetes v1.33, which can be enabled through the Kubernetes `HPAConfigurableTolerance` feature gate. As of Kubernetes v1.34, this field has graduated to beta release and is specifiable by default. ### scalingModifiers If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional). There is one important exception to the activation target for scaling modifiers and that is [external push scalers](../concepts/external-scalers). These scalers can implement `StreamIsActive` gRPC method which pushes activation status to KEDA directly, regardless of what the metric value and activation target is. #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.19/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.19/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.19/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false ensureEvenDistributionOfPartitions: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### New `ensureEvenDistributionOfPartitions` property support When scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to. Consider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution. Below are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default. - For lag between `1 -> 10` we would be running `1` consumer - For lag between `11 -> 20` we would be running `2` consumer - For lag between `21 -> 50` we would be running `5` consumers - For lag higher than `51` we would be running `10` consumers ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.19/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' ensureEvenDistributionOfPartitions: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### New `ensureEvenDistributionOfPartitions` property support When scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to. Consider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution. Below are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default. - For lag between `1 -> 10` we would be running `1` consumer - For lag between `11 -> 20` we would be running `2` consumer - For lag between `21 -> 50` we would be running `5` consumers - For lag higher than `51` we would be running `10` consumers ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.19/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Datastore" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.19/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. **TLS authentication:** - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - Password for the client certificate private key. (Optional, Required when `key` is encrypted) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ### Example with TLS (HTTPS with self-signed certificates) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8443" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" unsafeSsl: "true" # Skip certificate validation for self-signed certificates authenticationRef: name: trigger-auth-kedartemis ``` ### Example with mutual TLS (client certificates) ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis-tls namespace: kedartemis type: Opaque data: artemis-ca: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=" # Base64 encoded CA certificate artemis-cert: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=" # Base64 encoded client certificate artemis-key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi4uLgo=" # Base64 encoded client private key --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis-tls namespace: kedartemis spec: secretTargetRef: - parameter: ca name: kedartemis-tls key: artemis-ca - parameter: cert name: kedartemis-tls key: artemis-cert - parameter: key name: kedartemis-tls key: artemis-key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8443" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" authenticationRef: name: trigger-auth-kedartemis-tls ``` ================================================ FILE: content/docs/2.19/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Optional: ignoreNullValues ignoreNullValues: "false" # Required: region awsRegion: "eu-west-1" # Optional: Specify metric source AWS Account ID when using CloudWatch cross-account observability awsAccountId: "" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsAccountId` - Specify metric source AWS Account ID when using CloudWatch cross-account observability - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). Supports all CloudWatch statistics including percentiles (e.g., `p95`, `p50`) and trimmed means (e.g., `tm99`, `tm95`). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response. If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional) > Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload. - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.19/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.19/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}, ":filterValue" : {"S" : "hello world"}}' # Optional: filterExpression filterExpression: 'filterField = :filterValue' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `filterExpression` - the condition that specifies the filterExpression to be used by the Query action. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.19/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.19/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.19/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.19/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.19/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) > When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.19/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" # Optional. Custom timeout for the HTTP client used in this scaler timeout: "1000" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides ### Links - [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) - [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity) - [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity) ================================================ FILE: content/docs/2.19/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "0.5" activationTargetValue: "3.5" activeDirectoryClientId: # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.19/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: Require jobs to include specified demands, ignoring any extra ones requireAllDemandsAndIgnoreOthers: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" # Optional: Whether to only fetch unfinished jobs from the API (default: false) fetchUnfinishedJobsOnly: false # Optional: Property to enable case-insensitive comparison of pipeline job demands (default: false) caseInsensitiveDemandsProcessing: false authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME". Mutually exclusive with `jobsToFetch`. - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API. Mutually exclusive with `parent` and `fetchUnfinishedJobsOnly`. (Default: `250`, Optional) - `fetchUnfinishedJobsOnly` - Whether to fetch only unfinished jobs from the Azure Pipeline API. Normally both finished, running and pending jobs are returned by the API. When this parameter is set to `true`, the API call is modified so that only running and pending jobs are returned from the API, which reduces the amount of returned jobs considerably. Mutually exclusive with `jobsToFetch`. (Default: `false`, Optional) - `caseInsensitiveDemandsProcessing` - Property to enable case-insensitive comparison of pipeline job demands. When this parameter is set to `true`, the demands check is case-insensitive. (Default: `false`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not use demands in your agent scaler then it scales based on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list. - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. However, as this an undocumented API, it possesses some unique quirks when calling it with different query parameters. For example, if the `$top` query parameter is given, the format of the returned JSON is changed in such a way that it is no longer possible for the scaler to find the matched agents; making it impossible to use with the `parent` property from the trigger metadata. Therefore making `jobsToFetch` mutually exclusive with `parent` in the trigger metadata. Additionally, the `$top` query parameter takes precedence over some other parameters like `completedRequestCount`. If the `$top` query parameter is given, finished jobs are included in the response even if `completedRequestCount=0` is given, although `completedRequestCount=0` would indicate that only pending and running jobs should be returned. Thus, `jobsToFetch` is also mutually exclusive with `fetchUnfinishedJobsOnly` in the trigger metadata. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.19/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.19/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.19/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' queueLengthStrategy: all|visibleonly activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 # Optional queueLengthStrategy: "all" # or visibleonly. Default: all cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.19/scalers/beanstalkd.md ================================================ +++ title = "Beanstalkd" availability = "v2.16+" maintainer = "Community" description = "Scale applications based on beanstalkd queues" go_file = "beanstalkd_scaler" +++ ### Trigger Specification This specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue. ```yaml triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 includeDelayed: "false" tube: "default" activationValue: "10" value: "15" timeout: "30" ``` **Parameter list:** - `server` - Address of beanstalkd server `:`. If no port is specified then the scaler will default to `11300`. - `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted. - `tube` - Name of the tube to scale on. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set. - `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional) ### Authentication Parameters No authentication should be needed to connect to the beanstalkd server. ### Example #### Default tube with activation value Here the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'default' activationValue: "10" value: "20" ``` #### User-created tube with minimum replicas A minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'scaling-tube' value: "5" includeDelayed: "true" ``` ================================================ FILE: content/docs/2.19/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. - `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional). - `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional) - `key` - Key path for client authentication. Mandatory if tls enabled. (Optional) ### Example with no TLS auth ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ### Example with TLS auth Since we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes: - name: temp-cassandra-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes.keda.extraVolumes - name: temp-cassandra-vol emptyDir: medium: Memory ``` Once we have the writable mount path set up for the certificates and keys. ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD tls: enable cert: key: ## Optional parameter ca ## ca: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password - parameter: tls name: cassandra-secrets key: tls - parameter: cert name: cassandra-secrets key: cert - parameter: key name: cassandra-secrets key: key ## Optional parameter ca ## - parameter: ca name: cassandra-secrets key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.19/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.19/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.19/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be the same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale your deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do it the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.19/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). There are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately. ## Using the Datadog Cluster Agent (Experimental) With this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches. ### Deploy the Datadog Cluster Agent with enabled external metrics First, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA). If you are using Helm to deploy the Cluster Agent, set: * `clusterAgent.metricsProvider.enabled` to `true` * `clusterAgent.metricsProvider.registerAPIService` to `false` * `clusterAgent.metricsProvider.useDatadogMetrics` to `true` * `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}]` If you are using the Datadog Operator, add the following options to your `DatadogAgent` object: ``` apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: name: datadog spec: features: externalMetricsServer: enabled: true useDatadogMetrics: true registerAPIService: false override: clusterAgent: env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}] [...] ``` NOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later. ### Create a DatadogMetric object for each scaling query To use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: "true"` annotation, to ensure the Cluster Agent retrieves the query value. Example: ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: annotations: external-metrics.datadoghq.com/always-active: "true" name: nginx-hits spec: query: sum:nginx.net.request_per_s{kube_deployment:nginx} ``` ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType metricUnavailableValue: "1.5" timeout: "10s" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional) - `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events. - `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events. - `targetValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) - `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. > 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as "no data" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA. ### Authentication The Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below: **Common to all authentication types** - `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional) - `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed. - `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern. - `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional) **Bearer authentication:** - `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated. ### Example ```yaml apiVersion: v1 kind: ConfigMap metadata: name: datadog-config namespace: my-project data: datadogNamespace: # Required: namespace where the Datadog Cluster Agent is deployed datadogMetricsService: # Required: Cluster Agent metrics server service name unsafeSsl: # Optional: set to "true" to skip SSL certificate validation authMode: # Required: authentication mode (bearer) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: datadog-cluster-agent-creds namespace: my-project spec: boundServiceAccountToken: - parameter: token serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io configMapTargetRef: - parameter: datadogNamespace name: datadog-config key: datadogNamespace - parameter: unsafeSsl name: datadog-config key: unsafeSsl - parameter: authMode name: datadog-config key: authMode - parameter: datadogMetricsService name: datadog-config key: datadogMetricsService --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx maxReplicaCount: 3 minReplicaCount: 1 pollingInterval: 60 triggers: - type: datadog metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "2" type: "global" timeout: "10s" authenticationRef: name: datadog-cluster-agent-creds ``` ## Using the Datadog REST API ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "false" query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" timeout: "10s" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false) - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) - `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. > 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as "no data" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" # Optional: the HTTP timeout for this trigger timeout: "10s" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ### Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../reference/scaledobject-spec/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ### Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. #### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. #### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ### Cases of unexpected metrics value in DataDog API response #### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue #### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.19/scalers/dynatrace.md ================================================ +++ title = "Dynatrace" availability = "2.15+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Dynatrace metric data points" go_file = "dynatrace_scaler" +++ ### Trigger Specification This specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points. ```yaml triggers: - type: dynatrace metadata: host: https://dummy-instance.live.dynatrace.com/ threshold: "10" # Optional activationThreshold: "5" # Optional metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' # Optional from: now-2d # Optional query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-2d' # Optional queryTimeoutSeconds: "10" # Optional queryPollingWait: "1s" # Optional queryPollingTries: "5" ``` **Parameter list:** - `host` - The Dynatrace instance to query against. (This value can be different when using `metricSelector` than when using `query`) - `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). (Optional, Mutually exclusive with `query`) Some relevant aspects: - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector - `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours, This only applies when `metricSelector` is used; with `query`, the time range must be included within the query) - `query` - [DQL](https://docs.dynatrace.com/docs/discover-dynatrace/platform/grail/dynatrace-query-language) query to be executed. (Optional, Mutually exclusive with `metricSelector`) Some relevant aspects: - Query must return a single scalar named `r` that KEDA will use as metric, other fields will be ignored. - KEDA will poll 5 times the value with a second between tries, so the query needs to have a result within that window. - `queryTimeoutSeconds` - Timeout in seconds passed to fetch data on Dynatrace side (Default: `10`, Optional, Only applies with `query`) - `queryPollingWait` - Time between result polling tries (Default: `1s`, Optional, Only applies with `query`) - `queryPollingTries` - Total polling tries (Default: `5`, Optional, Only applies with `query`) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float) > NOTE: Modifying the values of `queryPollingWait` or `queryPollingTries` can increase the response time and the HPA Controller can register timeouts because of this. If your query requires longer times, you should evaluate options like [caching metrics (`useCachedMetrics`)](./../reference/scaledobject-spec.md#triggers) in addition to these parameters. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication for the `host` and `token` parameters. **Authentication:** - `host` - The Dynatrace instance to query against (This value can be different when using `metricSelector` than when using `query`) - `token` - The API key that will be leveraged to connect to Dynatrace and make requests. For `metricSelector`, token requires the `metrics.read` scope ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). For `query`, token **[has to be a platform token](https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients/platform-tokens)** with enough permissions for the table that you want to use (OIDC client isn't supported). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/ token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' from: 'now-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ### DQL Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5hcHBzLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.apps.dynatrace.com/ token: ZHQwczE2LlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s16.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ### Troubleshooting & Tips #### Required Token Permissions for `query` Parameter When using the `query` parameter (DQL-based queries), your platform token must have **both** of the following scopes: - `storage:metrics:read` - `storage:buckets:read` > **Note:** This is different from `metricSelector`, which only requires `metrics.read`. #### Testing Your Query with Dynatrace Swagger UI You can test your DQL query directly as your token using the Dynatrace Swagger UI before configuring KEDA: ``` https://.apps.dynatrace.com/platform/swagger-ui/index.html?urls.primaryName=Grail+-+DQL+Query#/Query%20Execution/query%3Aexecute ``` Click the **Authorize** button (top right) and enter your platform token to authenticate. This lets you validate your query and permissions before using them in KEDA. #### Example: Scaling Based on GCP Pub/Sub via Dynatrace If your GCP project is onboarded into Dynatrace, you can scale based on Pub/Sub metrics using a DQL query like this: ```yaml triggers: - type: dynatrace metadata: query: >- timeseries value = max(cloud.gcp.pubsub_googleapis_com.subscription.num_unacked_messages_by_region, scalar:true), filter: gcp.project.id == "myproject", from: now()-5m | fields value | append [data record(value = 0.0)] | summarize r = toDouble(max(value)) ``` ================================================ FILE: content/docs/2.19/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html). The trigger always requires the following information, but requires either only searchTemplateName **or** only query: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" query: "my-query" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `query` - The query to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Examples Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" query: | { "size": 0, "query": { "bool": { "must": [ { "term": { "service.name": "my-application" } }, { "term": { "service.environment": "production" } }, { "range": { "@timestamp": { "gte": "now-2m", "lte": "now-1m" } } } ] } }, "aggs": { "transaction_count": { "cardinality": { "field": "transaction.id" } } } } valueLocation: "aggregations.transaction_count.value" targetValue: "1000" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.19/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' usernameFromEnv: # Optional passwordFromEnv: # Optional ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Password based authentication:** - `username` - Username for authentication. (Optional) - `password` - Password for authentication. (Optional) **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on Password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: etcd-username: etcd-password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-etcd-secrets key: etcd-username - parameter: password name: keda-etcd-secrets key: etcd-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.19/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.19/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem enableTLS: false unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.19/scalers/forgejo.md ================================================ +++ title = "Forgejo" availability = "v2.18+" maintainer = "Community" category = "CI/CD" description = "Scale applications based on pending jobs on Forgejo repository." go_file = "forgejo_scaler" +++ ### Trigger Specification This specification describes the `forgejo-runner` trigger for Forgejo Actions. It scales based on the amount of jobs pending in given runner labels. ```yaml triggers: - type: forgejo-runner metadata: # Required: the name of the registered runner name: "forgejo-runner-ubuntu" # Required: the url of the forgejo instance address: "http://localhost:3000" # Optional: Scope of the jobs to check, global is the default one and will get all the jobs in the instance with the defined labels global: "true" # Optional: User to set as a scope, global should be false, if no repo is set will get all the pending jobs for the user owner: "cobak" # Optional: Repository level scope repo: "my-repo" # Required: Will get the jobs with match with this labels labels: "ubuntu-latest" ``` **Parameter list:** - `name` - Name of the registered runner. - `address` - Url of the forgejo instance. - `global` - Scope of the jobs to check. (Values: `true`, `false`, Default: `true`, Optional, Mutually exclusive with `owner` and `repo`) - `owner` - User to set as a scope. (Optional, Mutually exclusive with `global` and `repo`) - `repo` - User to set as a scope. (Optional, Mutually exclusive with `global` and `owner`) - `labels` - Labels to match the job with. ### Authentication Parameters - `token` - Required token to connect to forgejo instance. ### Options on how to set the scope (global, user, repo) 1. If you set owner and repo KEDA forgejo scaler will retrieve jobs from that repository: ``` owner: "username" repo: "my_repo" ``` 2. If you set the organization will retrieve the organization jobs: ``` org: "my_org" ``` 3. If you set global: true will retrieve all the jobs from the instance ``` global: "true" ``` 4. And if you don't set any of this optional fields will retrieve the jobs from the user who creates the token ## Configuration ### Registering runners and binding config with autoscalers To match job endpoints with job execution, we need to pre-register a runner, save the generated JSON file as a ConfigMap, and share it with the autoscaler. review the different ways to register a runner [here](https://forgejo.org/docs/latest/admin/runner-installation/#standard-registration), select the desired scope (user, repository or global) and create the corresponding JSON file. Autoscaler definition and runner registration should match to work as expected. Create a .runner file and a registration file with this commands, and set the output in a configmap. ```shell docker run -v /var/run/docker.sock:/var/run/docker.sock -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner register --no-interactive --token xxxx --name runner --instance http://localhost:3000/ --labels ubuntu-20:docker://node:20-bookworm,docker:docker://ghcr.io/catthehacker/ubuntu:act-latest docker run -v /var/run/docker.sock:/var/run/docker.sock -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner generate-config > registration.yaml ``` ```yaml apiVersion: v1 kind: ConfigMap metadata: name: runner-config namespace: runners data: .runner: | { "WARNING": "This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.", "id": 3, "uuid": "be6b5260-e73f-4e21-af84-8e205dbaaacd", "name": "runner", "token": "", "address": "http://localhost:3000/", "labels": [ "ubuntu-20:docker://node:20-bookworm", "docker:docker://ghcr.io/catthehacker/ubuntu:act-latest" ] } --- apiVersion: v1 kind: ConfigMap metadata: name: runner-registration namespace: runners data: registration.yaml: | log: # The level of logging, can be trace, debug, info, warn, error, fatal level: info # The level of logging for jobs, can be trace, debug, info, earn, error, fatal job_level: info runner: # Where to store the registration result. file: /data/.runner # Execute how many tasks concurrently at the same time. capacity: 1 # Extra environment variables to run jobs. envs: DOCKER_HOST: tcp://localhost:2376 DOCKER_TLS_VERIFY: 1 DOCKER_CERT_PATH: /certs/client # Extra environment variables to run jobs from a file. # It will be ignored if it's empty or the file doesn't exist. env_file: .env # The timeout for a job to be finished. # Please note that the Forgejo instance also has a timeout (3h by default) for the job. # So the job could be stopped by the Forgejo instance if it's timeout is shorter than this. timeout: 3h # The timeout for the runner to wait for running jobs to finish when # shutting down because a TERM or INT signal has been received. Any # running jobs that haven't finished after this timeout will be # cancelled. # If unset or zero the jobs will be cancelled immediately. shutdown_timeout: 3h # Whether skip verifying the TLS certificate of the instance. insecure: false # The timeout for fetching the job from the Forgejo instance. fetch_timeout: 5s # The interval for fetching the job from the Forgejo instance. fetch_interval: 2s # The interval for reporting the job status and logs to the Forgejo instance. report_interval: 1s # The labels of a runner are used to determine which jobs the runner can run, and how to run them. # Like: ["macos-arm64:host", "ubuntu-latest:docker://node:20-bookworm", "ubuntu-22.04:docker://node:20-bookworm"] # If it's empty when registering, it will ask for inputting labels. # If it's empty when executing the `daemon`, it will use labels in the `.runner` file. labels: - ubuntu-20:docker://node:20-bookworm - docker:docker://ghcr.io/catthehacker/ubuntu:act-latest cache: # Enable cache server to use actions/cache. enabled: true # The directory to store the cache data. # If it's empty, the cache data will be stored in $HOME/.cache/actcache. dir: "" # The host of the cache server. # It's not for the address to listen, but the address to connect from job containers. # So 0.0.0.0 is a bad choice, leave it empty to detect automatically. host: "" # The port of the cache server. # 0 means to use a random available port. port: 0 # The port of the cache proxy. # 0 means to use a random available port. proxy_port: 0 # The external cache server URL. Valid only when enable is true. # If it's specified, it will be used to set the ACTIONS_CACHE_URL environment variable. The URL should generally end with "/". # Otherwise it will be set to the the URL of the internal cache server. external_server: "" # The shared cache secret. When communicating with a cache server, the runner uses this secret to verify the authenticity of the cache requests. # When using an external cache server it is required to set the same secret for the runner and the cache server. secret: "" # Overrides the ACTIONS_CACHE_URL passed to workflow containers. This should only be used if the runner host is not reachable from the # workflow containers, and requires further setup. actions_cache_url_override: "" container: # Specifies the network to which the container will connect. # Could be host, bridge or the name of a custom network. # If it's empty, create a network automatically. network: host # Whether to create networks with IPv6 enabled. Requires the Docker daemon to be set up accordingly. # Only takes effect if "network" is set to "". enable_ipv6: false # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker). privileged: false # And other options to be used when the container is started (eg, --add-host=my.forgejo.url:host-gateway). options: -v /certs/client:/certs/client # The parent directory of a job's working directory. # If it's empty, /workspace will be used. workdir_parent: # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted. # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to: # valid_volumes: # - data # - /src/*.json # If you want to allow any volume, please use the following configuration: # valid_volumes: # - '**' valid_volumes: - /certs/client # overrides the docker client host with the specified one. # If "-" or "", an available docker host will automatically be found. # If "automount", an available docker host will automatically be found and mounted in the job container (e.g. /var/run/docker.sock). # Otherwise the specified docker host will be used and an error will be returned if it doesn't work. docker_host: "-" # Pull docker image(s) even if already present force_pull: false # Rebuild local docker image(s) even if already present force_rebuild: false host: # The parent directory of a job's working directory. # If it's empty, $HOME/.cache/act/ will be used. workdir_parent: ``` ### Create a token on forgejo The autoscaler will continuously fetch new waiting jobs from Forgejo, so it requires a properly configured token with the appropriate permissions. Navigate to **Forgejo > User settings > Applications > Access Tokens** and generate a new token. This token will be used by the autoscaler ### Configuring KEDA Autoscaler Create a new custom resource with the required parameters and custom fields based on the scope chosen during runner registration. For example, set `global="true"` for global runners or specify `repo=xxx` and `owner=xxx` for repository level runners. Choose the runner image you want to use (>6.1 of forgejo runner releases) or a custom one with `--one-job` command. Apply the new custom resource to your cluster. ```yaml apiVersion: v1 kind: Secret metadata: name: forgejo-runner-secret namespace: runners data: token: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: forgejo-runner-creds namespace: runners spec: secretTargetRef: - parameter: token name: forgejo-runner-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: labels: app: forgejo-runner name: upload-platform-forgejo-runner namespace: runners spec: jobTargetRef: template: metadata: labels: app: forgejo-runner spec: volumes: - name: runner-data emptyDir: {} - name: runner-config configMap: name: upload-platform-runner-config - name: runner-registration configMap: name: upload-platform-runner-registration - name: docker-certs emptyDir: {} restartPolicy: Never shareProcessNamespace: true containers: - name: runner image: code.forgejo.org/forgejo/runner:6.3.1 command: - sh - -c - | while ! nc -z localhost 2376 &1 & while kill -0 7 2>/dev/null do sleep 10 echo "watching main job execution" done; sleep 10 echo "main container exited, stopping dind" exit 0 env: - name: DOCKER_TLS_CERTDIR value: /certs - name: DOCKER_HOST value: tcp://0.0.0.0:2376 securityContext: privileged: true runAsUser: 0 volumeMounts: - name: docker-certs mountPath: /certs minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: forgejo-runner metadata: name: "runner" address: "http://localhost:3000/" global: "true" labels: "ubuntu-20,docker" authenticationRef: name: forgejo-runner-creds ``` ================================================ FILE: content/docs/2.19/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 filterDuration: '1' # Optional - Default is 2 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.19/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # The 'subscriptionSize' setting is DEPRECATED and will be removed in v2.20 - Use 'mode' and 'value' instead" mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 valueIfNull: '0.0' # Optional - Default is "" activationValue: "10.5" # Optional - Default is 0 timeHorizon: "1m" # Optional - Default is 2m and with aggregation 5m # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`) - `valueIfNull` - Value returned if request returns no timeseries.(Default: `""`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.19/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" filterDuration: '1' # Optional - Default is 2 activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.19/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.19/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false", defaults to "false" (scale on default runner labels) noDefaultLabels: "{noDefaultLabels}" # Optional: When enabled unlabeled jobs will not match unlabeled runners. Can be either "true" or "false", defaults to "false" matchUnlabeledJobsWithUnlabeledRunners: "{matchUnlabeledJobsWithUnlabeledRunners}" # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either "true" or "false", defaults to "false" enableEtags: "{enableEtags}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabels` - Not scale on default runner labels ("self-hosted", "linux", "x64"). (Values: `true`,`false`, Default: "false", Optional) - `matchUnlabeledJobsWithUnlabeledRunners` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: "false", Optional) - `enableEtags` - Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabelsFromEnv` - Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false". (Optional) - `matchUnlabeledJobsWithUnlabeledRunnersFromEnv` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) Example: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations: - Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories. - Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`. Note: This does not apply to a hosted appliance as there are no rate limits. Additional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour. **Fine-Tuning** The current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters. For example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly. *Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).* At the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.19/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.19/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) (**The 'minMetricValue' setting is DEPRECATED and will be removed in v2.20 - Use 'activationTargetMetricValue' instead**) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.19/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret unsafeSsl: "false" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ). - `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example Example with Basic Auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` Example with Basic Auth and TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password cert: key: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD - parameter: cert name: keda-ibmmq-secret key: cert - parameter: key name: keda-ibmmq-secret key: key ``` ================================================ FILE: content/docs/2.19/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org # Required for InfluxDB v2.x, optional for InfluxDB v3.x organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") metricKey: 'mymetric' # Required for Influx v3. Ignored for v2. See details in "Parameter List" section queryType: 'InfluxQL' # Required for Influx v3. Ignored for v2. See details in "Parameter List" section influxVersion: '2' # Optional: Defaults to 2. database: 'some-influx-db' # Required for Influx v3 authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc (Optional, Required if `influxVersion: '2'`). - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `influxVersion` - Specifies the version of InfluxDB being used. (Values: `2`, `3`, Default: `2`, Optional) - `database` - The name of the InfluxDB database to query. Required for InfluxDB v3.x. (Optional for InfluxDB v2.x) - `metricKey` - The name of the metric to be used for scaling decisions. This is required for InfluxDB v3.x and ignored for InfluxDB v2.x. It is used to identify the metric in the query results. For a `query` of `SELECT mean("mymetric") AS "metric_name" FROM...` use `metricKey: 'metric_name'`. (Optional, Required if `influxVersion: '3'`) - `queryType` - Specifies the type of query being used. For InfluxDB v3.x, this can be either `InfluxQL` or `FlightSQL`. For InfluxDB v2.x, this parameter is ignored. (Values: `InfluxQL`, `FlightSQL`, Default: `InfluxQL`, Optional) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example (InfluxDB v2) Below is an example of how to deploy a scaled object with the `InfluxDB` (v2) scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ### Example (InfluxDB v3) Below is a similar example for Influx v3 using an `InfluxQL` query. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 database: 'my-metrics-db' influxVersion: '3' queryType: 'InfluxQL' metricKey: 'mean' thresholdValue: '2' activationThresholdValue: '10' query: | SELECT mean("water_level") FROM "h2o_feet" GROUP BY time(5m) ORDER BY time DESC LIMIT 1; authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.19/scalers/kubernetes-resource.md ================================================ +++ title = "Kubernetes Resource" availability = "v2.19+" maintainer = "Community" category = "Kubernetes" description = "Scale applications based on values in Kubernetes ConfigMaps or Secrets" go_file = "kubernetes_resource_scaler" +++ ### Trigger Specification This specification describes the `kubernetes-resource` trigger that scales based on a value found in a Kubernetes ConfigMap or Secret. This scaler allows users to scale workloads by extracting values from Kubernetes resources, supporting number, JSON, and YAML formats. Here is an example of trigger configuration using kubernetes-resource scaler: ```yaml triggers: - type: kubernetes-resource metadata: resourceKind: "Secret" resourceName: "my-secret" key: "data" format: "json" valueLocation: "count" valueType: "float64" targetValue: "10" activationTargetValue: "5" ``` **Parameter list:** - `resourceKind` - Type of Kubernetes resource to read from. Supported values: `ConfigMap`, `Secret` (Required) - `resourceName` - Name of the resource to read. (Required) - `key` - Key in the ConfigMap's `data` field or Secret's `data` field to read from. The value at this key is retrieved as a string. (Required) - `format` - Format of the string value retrieved from `key`. Supported values: `number`, `json`, `yaml`. (Default: `number`, Optional) - `number` - The string value is parsed directly as a number - `json` - The string value is a JSON document, and `valueLocation` extracts a field from it - `yaml` - The string value is a YAML document, and `valueLocation` extracts a field from it - `valueLocation` - Path to extract the metric value from the JSON or YAML content retrieved from `key`. Required for `json` and `yaml` formats. Not used for `number` format. For `json`, use [GJSON path notation](https://github.com/tidwall/gjson#path-syntax). For `yaml`, use dot-separated path (e.g., `foo.bar.count`). (Optional) - `valueType` - Type of value to extract. Supported values: `float64`, `int64`, `quantity`. (Default: `float64`, Optional) - `float64` - Floating point number. For JSON format, accepts both numbers and quantity strings. - `int64` - Integer number. For JSON format, only accepts integer numbers (decimal values are truncated). For `number` format, the string must be parseable as an integer. - `quantity` - Kubernetes quantity (e.g., "100m", "1Gi"). For JSON/YAML formats, parses string values as quantities. For JSON format, also accepts raw numbers. - `targetValue` - Target value to scale on. When the extracted value is equal or higher, KEDA will scale out. (Required) - `activationTargetValue` - Value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters No authentication parameters are required. The scaler uses the permissions of the KEDA operator to access resources in the same namespace. ### Example Here is a full example of scaled object definition using Kubernetes Resource trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: k8s-resource-scaledobject namespace: keda spec: maxReplicaCount: 10 scaleTargetRef: name: dummy triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "my-configmap" key: "metrics" format: "yaml" valueLocation: "count" valueType: "int64" targetValue: "10" ``` Assuming the ConfigMap contains: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: my-configmap namespace: keda data: metrics: | count: 12 other: value ``` The scaler will extract the value at `count` from the YAML data in the `metrics` key and use it for scaling decisions. > 💡 **NOTE:** > - The `valueType` parameter controls how values are parsed. For `int64`, decimal values in JSON are truncated to integers. > - For `json` format, use GJSON path syntax. For `yaml` format, use dot-separated path. For `number` format, the value at the key is used directly. > - For YAML format, the `valueType` determines how the extracted value is converted, regardless of whether the value is a string or a native YAML number. For example, if `valueType` is set to `int64`, the value will be converted to an integer; if set to `quantity`, it will be parsed as a Kubernetes quantity. By default, numeric YAML values are converted to float64 unless a different `valueType` is specified. ### Additional Examples #### Example 1: Number Format (Direct Value) ```yaml apiVersion: v1 kind: ConfigMap metadata: name: task-count namespace: keda data: count: "42" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: task-scaler namespace: keda spec: scaleTargetRef: name: worker-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "task-count" key: "count" format: "number" valueType: "float64" targetValue: "50" activationTargetValue: "10" ``` In this example, the value `42` from the `count` key is used directly. #### Example 2: JSON Format ```yaml apiVersion: v1 kind: Secret metadata: name: metrics-data namespace: keda stringData: metrics: | { "queue": { "pending": 25, "processing": 5 } } --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: queue-scaler namespace: keda spec: scaleTargetRef: name: processor-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "Secret" resourceName: "metrics-data" key: "metrics" format: "json" valueLocation: "queue.pending" valueType: "int64" targetValue: "20" ``` In this example, the GJSON path `queue.pending` extracts the value `25` from the JSON data. #### Example 3: YAML Format with Nested Path ```yaml apiVersion: v1 kind: ConfigMap metadata: name: app-metrics namespace: keda data: stats: | application: workers: active: 15 idle: 3 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: worker-scaler namespace: keda spec: scaleTargetRef: name: worker-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "app-metrics" key: "stats" format: "yaml" valueLocation: "application.workers.active" valueType: "int64" targetValue: "10" ``` In this example, the dot-separated path `application.workers.active` extracts the value `15` from the YAML data. #### Example 4: Quantity Type ```yaml apiVersion: v1 kind: ConfigMap metadata: name: resource-limits namespace: keda data: memory: | { "available": "2Gi", "used": "512Mi" } --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaler namespace: keda spec: scaleTargetRef: name: worker-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "resource-limits" key: "memory" format: "json" valueLocation: "used" valueType: "quantity" targetValue: "1024000000" # 1Gi in bytes ``` In this example, the quantity string `"512Mi"` is parsed and converted to its float64 representation for scaling decisions. > ⚠️ **Important:** When using `valueType: "int64"` with JSON format, decimal values will be truncated. For example, if the JSON contains `{"count": 25.7}`, it will be treated as `25`. ### Supported Formats and Value Extraction The scaler works in two steps: 1. **Retrieve the raw string**: Read the value from `ConfigMap.data[key]` or `Secret.data[key]` 2. **Extract the metric**: Parse the raw string based on the `format`: - **number**: The raw string is parsed directly as a number. No `valueLocation` is needed. - Example: If `key="count"` and `ConfigMap.data.count = "42"`, the metric value is `42` - **json**: The raw string is parsed as JSON, then `valueLocation` (using GJSON syntax) extracts the metric value. - Example: If `key="metrics"` and `ConfigMap.data.metrics = '{"tasks": 10}'`, with `valueLocation="tasks"`, the metric value is `10` - **yaml**: The raw string is parsed as YAML, then `valueLocation` (using dot-separated path) extracts the metric value. - Example: If `key="stats"` and `ConfigMap.data.stats = 'count: 15'`, with `valueLocation="count"`, the metric value is `15` ### Limitations - Only resources in the same namespace as the ScaledObject are supported. - No cross-namespace access. - Only ConfigMaps and Secrets are supported. - The scaler uses the KEDA operator's service account permissions to access resources. ### See Also - [KEDA Concepts: Activating and Scaling Thresholds](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) - [GJSON Path Syntax](https://github.com/tidwall/gjson#path-syntax) ================================================ FILE: content/docs/2.19/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.19/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.19/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.19/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.19/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). If `aggregateFromKubeServiceEndpoints` is set to `true`, the URL must use Kubernetes DNS format: `http://.[.svc.cluster.local]:/path`, where the port must be the pod port targeted by the service, not the service port. - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `aggregateFromKubeServiceEndpoints` - Whether to treat `url` as a kubernetes service and scrape/aggregate metrics for all of this service's endpoints. (Values: `true`, `false`, Default: `false`, Optional) - `aggregationType` - How to aggregate metrics when `aggregateFromKubeServiceEndpoints` is set to `true`, ignored otherwise. (Values: `average`, `sum`, `max`, `min`, Default: `average`, Optional) ### Note on aggregation from kubernetes service when setting `aggregateFromKubeServiceEndpoints: true` in metadata, Metrics API Scaler is able to compute basic `average`, `sum`, `min` or `max` aggregation asked by `aggregationType` metadata from all endpoint targets of a kubernetes API service, which is a handy feature in an environment where one didn't set up a metric aggregator/scraping stack (i.e prometheus), or simply doesn't want to use their monitoring stack to fetch and serve metrics from customers workload in their own kubernetes clusters, and leave the metrics API's responsibility up to the customer This specific behavior comes from the fact that querying a kubernetes service directly (= setting `aggregateFromKubeServiceEndpoints: false`) would return the metric from a single replica randomly, depending on the load-balancing configuration for the service, and lead to inconsistent HPA average metric computation and eventually to scaling issues as metrics from all replicas won't be taken into account Here is an example of a ScaledObject using `aggregateFromKubeServiceEndpoints`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "8.8" url: "http://my-service.my-namespace.svc.cluster.local:8080/api/v1/stats" valueLocation: "components.worker.tasks" aggregateFromKubeServiceEndpoints: "true" aggregationType: "sum" ``` ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below. Multiple authentication methods can be used simultaneously by providing a comma-separated list in the `authMode` parameter, for example `authMode: "apiKey,tls"` enables both API key and TLS certificate authentication in a single request. **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.19/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. This value can be a float. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.19/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.19/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.19/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.19/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example Autoscaling trigger based on transaction duration average metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` Autoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO" noDataError: "true" threshold: '300' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.19/scalers/nsq.md ================================================ +++ title = "NSQ" availability = "v2.17+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NSQ topic/channel depth." go_file = "nsq_scaler" +++ ### Trigger Specification This specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. ```yaml triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" useHttps: "false" unsafeSsl: "false" ``` **Parameter list:** - `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `:`. - `topic` - Name of the NSQ datastream that the `channel` relates to. - `channel` - Name of the channel used to calculate depth. - `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional) - `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional) - `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) > **Notice:** > - Since ["channels are created on first use by subscribing to the named channel"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0. > - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nsq-scaledobject spec: scaleTargetRef: name: nsq-consumer-deployment triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" ``` ================================================ FILE: content/docs/2.19/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.19/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.19/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for three connection options: A user can offer a full connection string (often in the form of an environment variable secret). - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. It is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity. More details and an example are provided down below. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return a numeric value (integers and floats are both supported). - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` **Azure Access Token authentication:** #### Prerequisites: - The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity). - The UAMI should be granted access to the table mentioned in the query performed by KEDA. This can be achieved by: - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role. - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like `GRANT ALL ON TO "";`. Next, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process. - `host` - FQDN of the Azure Postgres Flexible Server. - `userName` - Name of the UAMI Azure identity (``). - `port` - Postgresql port (the default value is `"5432"`, please have a look at the `Remarks` down below). - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database (the value should be `require`). #### Remarks - While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-pg-flex-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql authenticationRef: name: azure-pg-flex-auth metadata: host: port: "5432" userName: dbName: sslmode: require query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.19/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.19/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint timeout: "1000" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) - `timeout` - Timeout **for this specific trigger**. Can be given as a number (in milliseconds) or in a human-readable format like "30s". This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.19/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.19/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://:/ # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either `amqp`, `http`, or `auto` for auto-detection based on the `host` value. Default value is `auto`. mode: QueueLength # Supported modes are `QueueLength`, `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` or `ExpectedQueueConsumptionTime` value: "100.50" # A value defining the threshold (per instance) that, when exceeded, triggers the scaling. activationValue: "10.5" # Optional. Activation threshold, which by default is 0. queueName: testqueue # Name of the queue. vhostName: / # Optional. If not specified, use the VHost in the `host` connection string. Required for Azure AD Workload Identity authorization (see below). # You can use existing environment variables to read configuration from. For details see "Parameters list" section. hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter. usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of `TriggerAuthentication`. passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of `TriggerAuthentication`. unsafeSsl: true # Optional. Whether to allow unsafe SSL connections. timeout: 1000 # Optional. Custom timeout for the HTTP client used in this scaler. ``` **Parameters list:** - `host` - RabbitMQ host address in the format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example, the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain `vhost`, then the trailing slash is required, e.g. `http://guest:password@localhost:5672/`. When using a username with password consider using `hostFromEnv` or a `TriggerAuthentication`. - `queueName` - Name of the queue to read required information and stats from. - `mode` - Trigger mode. See [Choosing the right trigger mode](#choosing-the-right-trigger-mode) for additional details. Can be one of: - `QueueLength` - trigger on number of messages in the queue - `MessageRate` - trigger on the publishing rate reported by the queue - `DeliverGetRate` - trigger on the rate of delivered messages (to consumers or in response to `basic.get`, both acknowledged and not) reported by the queue - `PublishedToDeliveredRatio` - trigger on the value of ratio of `MessageRate` to `DeliverGetRate` - `ExpectedQueueConsumptionTime` - trigger on the value of expected time (in seconds) of consumption of all messages currently available in the queue (utilizes `QueueLength`, `MessageRate` and `DeliverGetRate` metrics). - `value` - A value defining the threshold (per instance) that, when exceeded, triggers the scaling (can be a floating-point number depending on the trigger mode). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) (default: `0`; optional; can be a floating-point number). - `protocol` - Protocol to be used for communication (values: `auto`, `http`, `amqp`; default: `auto`; optional). - `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (it's optional by default but **it is required** if Azure AD Workload Identity authorization is used). - `queueLength` - **DEPRECATED: please use `mode: QueueLength` and `value: ##` instead**. Defines a threshold value for the queue length passed to the scaler. For example: if one pod can handle 10 messages, set the queue length target to `10`. If the actual number of messages in the queue is 30, the scaler will scale up to 3 pods. Default is set to `20` unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of using full name (values: `true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol). - `pageSize` - This parameter allows setting the page size (default: `100`; optional; only applies when `useRegex` is set to `true`). - `operation` - Operation that will be applied to compute the number of messages in case when `useRegex` is enabled (values: `sum`, `max`, `avg`; defaults: `sum`; optional). - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT` (optional; only applies to hosts that use the `http` protocol). - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (ready messages only; values:`true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol). - `unsafeSsl` - Whether to allow unsafe SSL connections (values: `true`, `false`, default: `false`). Some parameters can be provided using environment variables instead of setting them directly in metadata: - `hostFromEnv` - reads the host and port of the RabbitMQ server from selected environment variable (in similar format as `host` parameter) - `usernameFromEnv` - reads the username from selected environment variable, which is used to connect to the broker’s management endpoint - `passwordFromEnv` - reads the password from selected environment variable, which is used to connect to the broker’s management endpoint. > 💡 **Notes:** > - `host`/`hostFromEnv` has an optional VHost name after the host slash which will be used to scope API request > - when using `host`/`hostFromEnv` or `TriggerAuthentication`, the supplied password cannot contain special characters > - trigger modes `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` require `http` protocol. > - setting `useRegex` to `true` also requires `protocol` to be set to `http`. > ⚠ **Important:** > - If you have unacknowledged messages and you want to have these counted for the scaling to happen, make sure to utilize the `http` protocol (only REST API interface allows for these to be counted). > - If scaling against many is desired, then the `ScaledObject` should have all desired triggers defined. HPA will scale based on the largest result considering each of triggers independently. ### Choosing the right trigger mode Below you can find available trigger modes with most common usage scenarios: - `QueueLength` - Mainly used to scale messages consuming services, where it is desired to keep number of messages in the queue at selected, nominal level. - `MessageRate` - Mainly used to scale messages consuming services, where it is desired to keep the consumption rate up to messages publication rate (or higher). - `DeliverGetRate` - This specific trigger is actually a byproduct of the resulting implementation of `PublishedToDeliveredRatio` trigger (it was implemented to be used within `scalingModifiers` as a part of composite metric), yet it still has its use in some scenarios. E.g. assuming there's a well known consumer service performance ballpark, `DeliverGetRate` trigger can be utilized to scale out messages publishing service in order to increase publication rate. In this particular example however, upper publication rate limit must be properly guarded by another trigger or by [`maxReplicaCount`](./../reference/scaledobject-spec/#maxreplicacount) so as not to scale infinitely (which could result in overloading the broker, or consumers, or both). - `PublishedToDeliveredRatio` - This trigger is used mainly to control consumer pods scaling to keep publishing and consuming rates at stable level. Assuming that this is the case, the principle of operation is this: - if publishing rate is greater than `value` (usually it is a value slightly above `1`), trigger will initiate scale-out process to launch more consumer pods - if publishing rate is equal to consumption rate (value `1`) then it is the indicator that capacity of consumers is sufficient for handling ongoing messages processing and no additional pods need to be added to the pool - if ratio is below `1`, HPA can gracefully take down some consumers but keep messages processing rate at stable level. - `ExpectedQueueConsumptionTime` - A trigger primarily used to scale consumer pods, which uses estimate value of pending time to deliver all available messages in the queue to the consumers. If it becomes active in this particular scenario, returned metric indicates growing number of messages due either increased publishing rate or degraded performance of currently active number of consumers. It relies on proper setting of `pollingInterval` (see below for details). > ⚠ **Important:** > - With `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` it is advised to set `metricType: Value` in the trigger configuration to rely on absolute metric value and not the average value across all scaled pods. For reference see [`triggers.metricType`](./../reference/scaledobject-spec/#triggers) and [`scalingModifiers.metricType`](./../reference/scaledobject-spec/#scalingmodifiersmetrictype). > - When using `PublishedToDeliveredRatio`, having stable publication to consumption rate may not indicate that consumers pool is of the right size to do the job, since the messages consuming capabilities can change over time, which may result in much higher number of consumers than actually needed. It is then recommended to periodically re-evaluate consumers pool size using different, probably external metric (e.g. consumers count number, size of prefetch buffer, consumer performance, etc.). > - Since `ExpectedQueueConsumptionTime` trigger mode is based on the expected time (in seconds) for the selected queue to be emptied of all messages (including estimated count of published messages during sample probing), it must be served with `pollingInterval` set to 1 second. However, in case where such frequent polling may be expensive, it is recommended to use `ExpectedQueueConsumptionTime` in `scalingModifiers` using additional triggers values in formula like so: `(ExpectedQueueConsumptionTime - (QueueLength / DeliverGetRate)) * pollingInterval + (QueueLength / DeliverGetRate)`. ### Authentication Parameters `TriggerAuthentication` CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. - `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (optional, but **required** if Azure AD Workload Identity authorization is used). #### Username and Password based authentication This allows sensitive credentials to be stored and managed separately from the connection string: - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** If username or password are set in `TriggerAuthentication` or environment variables, they will override any credentials provided in the `host` parameter. #### TLS authentication - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ will not be used. Valid values are `enable` or `disable` (optional; the default is `disable`). - `ca` - Certificate authority file for TLS client authentication (optional). - `cert` - Certificate for client authentication (optional). - `key` - Certificate Key for client authentication (optional). > 💡 **Note:** Using RabbitMQ host with AMQPS protocol will require enabling the TLS settings and passing the required parameters. #### Azure Workload Identity authentication For RabbitMQ with OIDC support (>= 3.11) you can use `TriggerAuthentication` CRD with `podIdentity.provider = azure-workload` and with `workloadIdentityResource` parameter, which will hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Currently, only HTTP protocol is supported for AKS Workload Identity. ### Configuration examples #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672 vhostName: vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: vhostName name: keda-rabbitmq-secret key: vhostName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQP protocol with username and password authorization: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://localhost:5672/vhost (no username/password) username: # base64 encoded value of username password: # base64 encoded value of password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: username name: keda-rabbitmq-secret key: username - parameter: password name: keda-rabbitmq-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS authorization: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `MessageRate` and `QueueLength` triggers): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger) and enabled `useRegex`: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `DeliverGetRate` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value metadata: protocol: http queueName: testqueue mode: DeliverGetRate value: "30" authenticationRef: name: rabbitmq-trigger-auth ``` #### HTTP protocol (with `PublishedToDeliveredRatio` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value metadata: protocol: http queueName: testqueue mode: PublishedToDeliveredRatio value: "1.1" authenticationRef: name: rabbitmq-trigger-auth ``` #### HTTP protocol (with `PublishedToDeliveredRatio` trigger used together with `scalingModifiers`) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value name: p2d_ratio metadata: protocol: http queueName: testqueue mode: PublishedToDeliveredRatio value: "1" authenticationRef: name: rabbitmq-trigger-auth - type: rabbitmq name: qlen metadata: protocol: http queueName: testqueue mode: QueueLength value: "100" authenticationRef: name: rabbitmq-trigger-auth advanced: # Bind QueueLength and PublishedToDeliveredRatio together to control trigger value scalingModifiers: metricType: Value # Trigger if either one of conditions is met: # - publishing to delivery rate exceeds factor of 1.2 # - queue length contains more than 1.2K messages formula: "max(p2d_ratio, qlen/1000)" target: 1.2 ``` #### HTTP protocol (with `ExpectedQueueConsumptionTime` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment pollingInterval: 1 triggers: - type: rabbitmq metricType: Value name: eqct metadata: protocol: http queueName: testqueue mode: ExpectedQueueConsumptionTime value: "20" authenticationRef: name: rabbitmq-trigger-auth ``` ================================================ FILE: content/docs/2.19/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.19/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.19/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.19/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.19/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "myprimary" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.19/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.19/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars, SeleniumHQ" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration with default values represent. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: '' # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`). browserVersion: '' # Optional. platformName: '' # Optional. unsafeSsl: false # Optional. activationThreshold: 0 # Optional. nodeMaxSessions: 1 # Optional. enableManagedDownloads: true # Optional. capabilities: '' # Optional. ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional). - `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional). - `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional) **Trigger Authentication** - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional) - `accessToken` - Access token. This is required when `authType` is set a value. (Optional) ### Example --- #### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion` Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' ``` Noted: - From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details. The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` With above script, the request is sent to Grid. Via GraphQL response, it looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 0, "totalSlots": 0 }, "nodesInfo": { "nodes": [] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` In Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata. When the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 1, "totalSlots": 1 }, "nodesInfo": { "nodes": [ { "id": "UUID-of-Node", "status": "UP", "sessionCount": 0, "maxSession": 1, "slotCount": 1, "stereotypes": "[{\"slots\": 1, \"stereotype\": {\"browserName\": \"chrome\", \"browserVersion\": \"\", \"platformName\": \"Linux\"}}]", "sessions": [] } ] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` Now, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in. --- #### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName` Moreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome-131 labels: deploymentName: selenium-node-chrome-131 spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:131.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '131.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-131 namespace: keda labels: deploymentName: selenium-node-chrome-131 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-131 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '131.0' unsafeSsl: 'true' ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '131.0') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` #### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads` In image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS value: "true" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Scaler trigger param configuration should be aligned with Node stereotype. enableManagedDownloads: "true" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid options.enable_downloads = True driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata with extra `capabilities` For an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options - name: SE_NODE_STEREOTYPE_EXTRA value: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536 capabilities: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes options.set_capability('myApp:version', 'beta') options.set_capability('myApp:publish', 'public') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Firefox browser ```yaml kind: Deployment metadata: name: selenium-node-firefox labels: deploymentName: selenium-node-firefox spec: replicas: 1 template: spec: containers: - name: selenium-node-firefox image: selenium/node-firefox:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-firefox namespace: keda labels: deploymentName: selenium-node-firefox spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-firefox triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = FirefoxOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Edge browser Similarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml kind: Deployment metadata: name: selenium-node-edge labels: deploymentName: selenium-node-edge spec: replicas: 1 template: spec: containers: - name: selenium-node-edge image: selenium/node-edge:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-edge namespace: keda labels: deploymentName: selenium-node-edge spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-edge triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = EdgeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions` In case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' - name: SE_NODE_OVERRIDE_MAX_SESSIONS value: 'true' - name: SE_NODE_MAX_SESSIONS value: '4' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' nodeMaxSessions: 4 unsafeSsl: 'true' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL graphql-username: base64 encoded value of GraphQL Username graphql-password: base64 encoded value of GraphQL Password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url - parameter: username name: selenium-grid-secret key: graphql-username - parameter: password name: selenium-grid-secret key: graphql-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.19/scalers/solace-pub-sub-dm.md ================================================ +++ title = "Solace PubSub+ Event Broker - Direct Messaging" availability = "2.18+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker - Direct Messaging" go_file = "solace_dm_scaler" +++ ### Trigger Specification This specification describes the `solace-direct-messaging` trigger that scales based on a Solace PubSub+ Event Broker direct messaging rates for all the clients in a message vpn that matches a common client name prefix. > 💡 **Note:** This trigger is for **Direct messaging** only, it provides the ability to scale the number of client instances automatically based upon transient metrics for shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length), all this metrics exists as long as the clients are connected. If you need to use **Guaranteed messaging** (Solace PubSub+ Event Broker queue) you should use the `solace-event-queue` trigger. ```yaml triggers: - type: solace-direct-messaging metricType: Value metadata: solaceSempBaseURL: "https://solace_broker1:943,https://solace_broker2:943" messageVpn: "message-vpn" clientNamePattern: "client-name-pattern" unsafeSSL: "true" queuedMessagesFactor: '3' aggregatedClientTxMsgRateTarget: '600' aggregatedClientTxByteRateTarget: '0' aggregatedClientAverageTxByteRateTarget: '0' aggregatedClientAverageTxMsgRateTarget: '0' usernameFromEnv: 'ENV_VAR_USER' passwordFromEnv: 'ENV_VAR_PWD' authenticationRef: name: trigger-authentication-ref ``` **Parameter list:** - `solaceSempBaseURL` - Comma separated list of Solace SEMP Endpoint in format: `://:`. (Required) - `messageVpn` - Message VPN hosted on the Solace broker from which the metrics will be collected. (Required) - `clientNamePattern` - Client name pattern that will be used to identify the clients that are consuming from a shared subscription. (Required). It will be used to match all the client names that match the expression: **' \*client-name-pattern\* '** - `unsafeSSL` - Flag to enable unsafe host urls (self signed certificates). (Default: `false`, Optional) - `queuedMessagesFactor` - Flag to to increase weight on queued messages (D-1) and scale faster to avoid discarding messages. (Default: `3`, Optional) - `aggregatedClientTxMsgRateTarget` - Target number messages per second the clients in the shared subscription are expected to consume, if the actual aggregated messages per second number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientTxByteRateTarget` - Target number bytes per second the clients in the shared subscription are expected to consume, if the actual aggregated bytes per second number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientAverageTxByteRateTarget` - Target average number messages per minute the clients in the shared subscription are expected to consume, if the actual aggregated messages per minute number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientAverageTxMsgRateTarget` - Target average number bytes per minute the clients in the shared subscription are expected to consume, if the actual aggregated bytes per minute number is greater the number of replicas will be increased. (Default: `0`, Optional) - `usernameFromEnv` - Environment variable set with SEMP user account. (Optional) - `passwordFromEnv` - Environment variable set with password for the user account. (Optional) **Parameter Requirements:** - Parameters resolving the target host and shared subscription are all **required:** `solaceSempBaseURL`, `messageVpn`, `clientNamePattern` - **At least** one of `aggregatedClientTxMsgRateTarget`, `aggregatedClientTxByteRateTarget`, `aggregatedClientAverageTxByteRateTarget` or `aggregatedClientAverageTxMsgRateTarget` is **required**. If more than one target values are present, calculation is done for each metric and the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) For more details please see [Horizontal Pod Autoscaling - Algorithm details](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) The `solace-direct-messaging` Scaler polls the Solace SEMP REST API to get transient metrics from connected clients. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the trigger to function. These values can be set in several different ways: - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 3 cooldownPeriod: 60 #Always > 0 because is direct messaging! minReplicaCount: 1 maxReplicaCount: 20 advanced: restoreToOriginalReplicaCount: true horizontalPodAutoscalerConfig: behavior: scaleDown: #The stabilization window is used to restrict the flapping of replica count when the metrics used for scaling keep fluctuating. #The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale. #All desired states from the past 1 minutes (60secs) will be considered stabilizationWindowSeconds: 60 #Policy (Pods) allows at most 1 replicas to be scaled down in 10 seconds. policies: - type: Pods value: 1 #Indicates the length of time in the past for which the policy must hold true periodSeconds: 10 scaleUp: stabilizationWindowSeconds: 0 #Policy (Pods) allows at most 3 replicas to be scaled up in 3 seconds. policies: - type: Pods value: 5 periodSeconds: 3 selectPolicy: Max triggers: - type: solace-direct-messaging #we don’t want to take the average of the given metric across all replicas, just the value metricType: Value metadata: solaceSempBaseURL: "https://broker1.messaging.solace.cloud:943,https://broker2.messaging.solace.cloud:943" messageVpn: "consumer_vpn" #all the clients that match this client name pattern will be considered for metric gathering clientNamePattern: "direct-messaging-simple" #to be able to use self signed certs unsafeSSL: "false" #to increase weight on queued messages and scale faster #if there are messages queued means we are behind queuedMessagesFactor: '3' #Metrics aggregatedClientTxMsgRateTarget: '600' aggregatedClientTxByteRateTarget: '0' aggregatedClientAverageTxByteRateTarget: '0' aggregatedClientAverageTxMsgRateTarget: '0' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.19/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. **Note:** This trigger is for **Guaranteed messaging** (Solace PubSub+ Event Broker queue) only, it provides the ability to scale the number of client instances automatically based upon metrics for a Solace PubSub+ Event Broker queue. If you need to use **Direct messaging**, shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length) you should use the `solace-direct-messaging` trigger. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint comma-separated host list in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **solaceSempBaseURL** can contain either a single URL or a comma-separated list of URLs. If multiple URLs are provided, the scaler will iterate over the list until it is both able to connect the broker successfully AND the broker's messageVpn is in the **UP** state. All brokers in the list will share the same authentication configuration. This feature was primarily added to support Solace's Disaster Recovery Replication feature. - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.19/scalers/solarwinds.md ================================================ +++ title = "SolarWinds" availability = "v2.18+" maintainer = "Community" description = "Scale applications based on metrics from SolarWinds." go_file = "solarwinds_scaler" +++ ### Trigger Specification This specification describes the `solarwinds` trigger that scales based on metrics from SolarWinds. ```yaml triggers: - type: solarwinds metadata: host: https://api.na-01.cloud.solarwinds.com targetValue: "1" activationValue: "3" metricName: "k8s.pod.cpu.usage.seconds.rate" aggregation: "AVG" intervalS: "60" filter: "k8s.deployment.name:my-deployment" ``` **Parameter list:** - `host` - The SolarWinds API endpoint. (Example: `https://api.na-01.cloud.solarwinds.com`) - `targetValue` - Value to reach to start scaling. (This value can be an integer or float) - `activationValue` - Target value for activating the scaler. (Optional, Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds)) - `metricName` - The name of the metric to monitor. - `aggregation` - The aggregation method to use. (Values: `COUNT`, `MIN`, `MAX`, `AVG`, `SUM`, `LAST`) - `intervalS` - The interval in seconds for the metric collection. - `filter` - The filter to apply to the metric data. (Optional, Examples below) - `key1:value1 key2:value2` - Search using key values pairs with a delimiting space for an implicit AND - `key:[value1,value2]` - Search using IN operator (key equals value1 or value2) - `key:~value` - Search using CONTAINS operator - `key>value1 key”, “<“, “<=”, “>=”) (key between value1 and value2) - `NOT key:""` - Search using NOT operator and EMPTY value (key is not empty) - `entities(attribute:value)` - search using attributes of entities related to the metric data (metric values associated with entity having attribute equals value) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing the necessary credentials. **Credential based authentication:** - `apiToken` - The API token for accessing SolarWinds Observability. See [doc](https://documentation.solarwinds.com/en/success_center/observability/content/settings/api-tokens.htm) for more information. ### Example Here is an example of a SolarWinds Scaler with authentication: ```yaml apiVersion: v1 kind: Secret metadata: name: solarwinds-secret namespace: default data: apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solarwinds-auth namespace: default spec: secretTargetRef: - parameter: apiToken name: solarwinds-secret key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solarwinds-scaledobject namespace: default spec: scaleTargetRef: name: nginx pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 2 triggers: - type: solarwinds authenticationRef: name: solarwinds-auth metadata: host: https://api.na-01.cloud.solarwinds.com targetValue: "3" activationValue: "3" metricName: "k8s.pod.cpu.usage.seconds.rate" aggregation: "AVG" intervalS: "60" filter: "k8s.deployment.name:my-deployment" ``` ================================================ FILE: content/docs/2.19/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.19/scalers/splunk-observability.md ================================================ +++ title = "Splunk Observability" availability = "v2.18+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk Observability Cloud metrics." go_file = "splunk_observability_scaler" +++ ### Trigger Specification This specification describes the `splunk-observability` trigger that scales based on the result of a metric series queried from the Splunk Observability Cloud platform with a [SignalFlow query](https://dev.splunk.com/observability/docs/signalflow/). ```yaml triggers: - type: splunk-observability metadata: # Required: SignalFlow query to retrieve the desired metric time series query: "data('demo.trans.latency').max().publish()" # Required: Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds duration: "10" # Required: Threshold to reach to start scaling targetValue: "400.1" # Required: Target value for activating the scaler activationTargetValue: "1.1" # Required: Specifies how the Metrics Time Series should be processed, options are "min" (minimum value), "max" (maximum value), and "avg" (average value) queryAggregator: "avg" ``` **Parameter list:** - `query` - SignalFlow query for querying the desired metrics. - `duration` - Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds. - `targetValue` - Threshold to reach to start scaling. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `queryAggregator` - When querying metrics from Splunk Observability Cloud, initially a Metric Time Series (MTS) is returned, a list consisting of several datapoints. The 'queryAggregator' specifies how this series of metrics should be "rolled up". Valid values for this field are "avg", which returns the average, "min", which returns the minimum of the metrics in the series, and "max", which returns the maximum value. **Parameter list:** - `accessToken` - Splunk Observability Cloud Access Token. - `realm` - Splunk Observability Cloud Realm. ## Configuration Example The following example shows how to scale a simple NGINX employment with the help of KEDA and the Splunk Observability Cloud scaler: #### Simple NGINX employment ```yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ``` #### Authentication ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-secrets data: accessToken: realm: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-splunk-secret spec: secretTargetRef: - parameter: accessToken name: splunk-secrets key: accessToken - parameter: realm name: splunk-secrets key: realm ``` #### KEDA Scaler ```yaml --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: splunk-observability metricType: Value metadata: query: "data('demo.trans.count', filter=filter('demo_host', 'server6'), rollup='rate').sum(by=['demo_host']).publish()" duration: "10" queryValue: "400.1" activationQueryValue: "1.1" queryAggregator: "max" # 'min', 'max', or 'avg' authenticationRef: name: keda-trigger-auth-splunk-secret ``` ================================================ FILE: content/docs/2.19/scalers/splunk.md ================================================ +++ title = "Splunk" availability = "v2.15+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk saved search results." go_file = "splunk_scaler" +++ ### Trigger Specification This specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches). The trigger always requires the following information: ```yaml triggers: - type: splunk metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "1" activationValue: "10" savedSearchName: my-saved-search-name valueField: count ``` **Parameter list:** - `host` - Search API host and port. Example: `https://localhost:8089`. - `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `"true"`, `"false"`, Default: `"false"`, Optional) - `targetValue` - Value to reach to start scaling (This value can be a integer or float). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `savedSearchName` - Name of saved search that returns metric data for scaling. - `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`. ### Authentication Parameters You can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication. > **Note:** > > `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API. **Parameter list:** - `username` - Splunk username authorized to access the search API. - `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`. - `password` - Password for supplied `username`. Conflicts with `apiToken`. The user will need access to the saved search. ### Examples ### Username/password ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### API Token ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # admin apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: apiToken name: splunk-creds key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### Full example using Splunk deployment ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: splunkconf data: default.yml: | splunk: conf: - key: savedsearches value: directory: /opt/splunk/etc/users/admin/search/local content: my-saved-search-name: action.email.useNSSubject: 1 action.webhook.enable_allowlist: 0 alert.track: 0 cron_schedule: '*/1 * * * *' dispatch.earliest_time: -15m dispatch.latest_time: now display.general.type: statistics display.page.search.tab: statistics display.visualizations.show: 0 enableSched: 1 request.ui_dispatch_app: search request.ui_dispatch_view: search search: index=_internal | tail | stats count --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: v1 kind: Service metadata: name: splunk spec: ports: - port: 8000 targetPort: web name: web-svc - port: 8089 targetPort: 8089 name: api-svc selector: app: splunk --- apiVersion: apps/v1 kind: Deployment metadata: name: splunk namespace: default spec: replicas: 1 selector: matchLabels: app: splunk template: metadata: labels: app: splunk spec: containers: - name: splunk image: splunk/splunk:9.2 ports: - containerPort: 8000 name: web - containerPort: 8089 name: api env: - name: SPLUNK_START_ARGS value: --accept-license - name: SPLUNK_PASSWORD value: password volumeMounts: - name: splunkconf-volume mountPath: /tmp/defaults volumes: - name: splunkconf-volume configMap: name: splunkconf --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8080 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 unsafeSsl: "true" targetValue: "5" activationValue: "5" savedSearchName: my-saved-search-name valueField: count ``` ================================================ FILE: content/docs/2.19/scalers/sumologic.md ================================================ +++ title = "Sumo Logic" availability = "v2.18+" maintainer = "Community" category = "Monitoring & Analytics" description = "Scale applications based on Sumo Logic logs searches and metrics queries." go_file = "sumologic_scaler" +++ ## Trigger Specification This specification describes the `sumologic` trigger that scales based on Sumo Logic logs searches and metrics queries. The scaler supports three different query types: - **`logs`** - Scale based on Sumo Logic logs query results - **`metrics`** - Scale based on single Sumo Logic metrics query results - **`metrics` (multi-query)** - Scale based on multiple combined Sumo Logic metrics queries Here are examples of the different trigger configurations: **Logs Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" # Sumo Logic API endpoint queryType: "logs" # Type must be "logs" query: "_view=my_view | count" # Your Sumo Logic logs query resultField: "_count" # Field to extract value from timerange: "15m" # Lookback window timezone: "Asia/Kolkata" # Timezone (e.g., Asia/Kolkata) queryAggregator: "Max" # Aggregation method: Latest, Avg, Sum, Count, Min, Max threshold: "1000" # Threshold for scaling authenticationRef: name: keda-trigger-auth-sumologic ``` **Single Metrics Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "metrics" query: "metric=cpu.usage | avg" quantization: "15s" rollup: "Max" timerange: "15m" timezone: "Asia/Kolkata" queryAggregator: "Max" threshold: "50" maxRetries: "3" # Optional: Maximum retry attempts authenticationRef: name: keda-trigger-auth-sumologic ``` **Multi-Metrics Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "metrics" query.A: "metric=requests_total | rate" query.B: "metric=request_capacity" query.C: "(#A / #B) * 100 along service" resultQueryRowID: "C" # Which query result to extract quantization: "15s" rollup: "Max" timerange: "15m" timezone: "Asia/Kolkata" queryAggregator: "Max" threshold: "75" authenticationRef: name: keda-trigger-auth-sumologic ``` **Parameter list:** **Common Parameters:** - `host` - Sumo Logic API endpoint URL (Based on your Geo). - `queryType` - Type of query. (Values: `logs`, `metrics`) - `query` - Sumo Logic query (for single queries). - `timerange` - Time range to evaluate the query. - `timezone` - Timezone for query execution. (Default: `UTC`, Optional) - `queryAggregator` - Aggregation method. (Values: `Latest`, `Avg`, `Sum`, `Count`, `Min`, `Max`, Default: `Avg`, Optional) - `threshold` - Target value for scaling. - `maxRetries` - Maximum number of retry attempts for API requests. (Default: `3`, Optional) **Logs Query Specific Parameters:** - `resultField` - Field from query results to extract the scaling metric. (Required when `queryType` is `logs`) - `logsPollingInterval` - Polling interval for log search job. (Default: `1s`, Optional) **Metrics Query Specific Parameters:** - `quantization` - Granularity of data points. (Required when `queryType` is `metrics`) - `rollup` - Metrics rollup type. (Values: `Avg`, `Sum`, `Min`, `Max`, `Count`, Default: `Avg`, Optional) **Multi-Metrics Query Specific Parameters:** - `query.A`, `query.B`, `query.C` etc - Multi-stage queries, where later queries can refer to earlier ones. (Required for multi-metrics queries) - `resultQueryRowID` - Which final query (`A`, `B`, `C`, etc.) to use for scaling. (Required for multi-metrics queries) ## Authentication Parameters You must configure a `TriggerAuthentication` resource to authenticate with Sumo Logic. **Prerequisites:** - A Sumo Logic Access ID and Access Key Authentication is handled through a Kubernetes `Secret` combined with a `TriggerAuthentication`: ```yaml apiVersion: v1 kind: Secret metadata: name: sumologic-auth-secret data: accessID: accessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-sumologic spec: secretTargetRef: - parameter: accessID name: sumologic-auth-secret key: accessID - parameter: accessKey name: sumologic-auth-secret key: accessKey ``` ### Example Here is a complete example that demonstrates autoscaling based on Sumo Logic logs query: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: sumologic-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "logs" query: "_view=error_logs | count" resultField: "_count" timerange: "5m" threshold: "100" authenticationRef: name: keda-trigger-auth-sumologic ``` ### Notes - `pollingInterval` controls how often KEDA polls Sumo Logic. - `cooldownPeriod` controls how long KEDA waits before scaling down. - `MetricType:` The scaler supports both `AverageValue` and `Value` metric types. - Ensure that the Sumo Logic user has **appropriate access** to the queries being executed. ================================================ FILE: content/docs/2.19/scalers/temporal.md ================================================ +++ title = "Temporal" availability = "v2.17+" maintainer = "Community" description = "Scale applications based on Temporal task queue." go_file = "temporal_scaler" +++ ### Trigger Specification This specification describes the `temporal` trigger that scales based on a Temporal task queue. ```yaml triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 queueTypes: workflow # optional buildId: 1.0.0 # optional selectAllActive: "false" # optional selectUnversioned: "false" # optional minConnectTimeout: "5" # optional unsafeSsl: "false" # optional tlsServerName: "custom-tls-servername" # optional ``` **Parameter list:** - `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `:`. (Required) - `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional) - `namespace` - The namespace of the temporal service. (Default:`default`, Optional) - `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional) - `taskQueue` - This parameter specifies the task queue name. (Required) - `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional) - `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional) - `selectAllActive` - Include all active versions (Default:`false`, Optional) - `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional) - `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional) - `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional) - `tlsServerName` - The custom tls server name (Optional) > 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero. This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog. Consequently, scaling to zero could result in undesirable behavior, such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA). By fine-tuning the configurations, you can prevent premature scaling to zero, ensuring that resources remain available for in-flight tasks or workloads with minimal throughput. **Authentication Parameters:** Temporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication: - `apiKey` - API key for authentication with temporal cloud. (Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: temporal-secret namespace: default type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-temporal namespace: default spec: secretTargetRef: - parameter: apiKey name: temporal-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject namespace: default spec: scaleTargetRef: name: workload-scaledobject pollingInterval: 5 cooldownPeriod: 10 minReplicaCount: 0 maxReplicaCount: 5 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 10 triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 authenticationRef: name: keda-trigger-auth-temporal ``` ================================================ FILE: content/docs/2.19/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.19/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.2/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.2/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.2/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.2/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.2/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.2/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.2/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.2/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.2/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.2/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.2/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.2/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interfaces: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. Few things to notice: - Lack of `Close` method as the GRPC connection defines the lifetime of the scaler - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` For `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.2/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml minReplicaCount: 0 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource. --- ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.2/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.2/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.2/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart ```sh helm install keda kedacore/keda --version 2.2.0 --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster you can run one of the following: ```sh helm uninstall keda -n keda ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.2.0`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.2.0/keda-2.2.0.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.2.0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.2.0 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.2.0`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.2.0/keda-2.2.0.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.2.0.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.2.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.2/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.2/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.2/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.2/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) ================================================ FILE: content/docs/2.2/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.2 has been tested on Kubernetes v1.16.0 or above. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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.This is only supported as of KEDA v2.6 if you are using our Helm chart. | ## 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: ```shell export KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` And on Windows Powershell, you'd use this command: ```shell $env:KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` All applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported. ================================================ FILE: content/docs/2.2/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted`| `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.2/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.2/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.2/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.2/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.2/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName dimensionName: QueueName # Required: Dimension Value - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Metric Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.2/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.2/concepts/authentication/). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.2/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) > For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.2/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." notice = "As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of event hub consumer. (Default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function. > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.2/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.2/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.2/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.2/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.2/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.2/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.2/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.2/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.2/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.2/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.2/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Password Authentication:** - `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager. - `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.2/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.2/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.2/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.2/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authMode` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.2/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server with database used.It would be written like this "portnumber/dbname" port: "27017/test" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server with the `dbName` separated by slash `/`. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `password` - Password for the configured user to login to MongoDB server. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.2/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. The default for MSSQL is 1433. - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the `database` value (if specified), or the `host` value, or will be in the form `mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.2/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `password` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.2/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/2.2/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.2/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.2/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Metric name to use. - `query` - Query to run. - `threshold` - Value to start scaling for. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` ================================================ FILE: content/docs/2.2/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100" # message backlog or publish/sec. target per instance queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.2/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.2/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.2/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.2/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.2/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.20/_index.md ================================================ +++ title = "Getting Started" description = "How you can start with KEDA as new user" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation bar on the left to learn more about KEDA's architecture and how to deploy and use KEDA. ## Where to go What is your involvement with KEDA? | Role | Documentation | |---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | User | This documentation is for users who want to deploy KEDA to scale Kubernetes. | | Core Contributor | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda). | | Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). | | Other Contributor | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers. | ================================================ FILE: content/docs/2.20/addons/_index.md ================================================ +++ title = "Add-ons" weight = 3 +++ Add-ons extend KEDA with support for specific use cases beyond the built-in scalers. ## HTTP Add-on The [HTTP Add-on](/http-add-on/latest/) enables autoscaling of HTTP-based workloads. It intercepts incoming HTTP requests and scales the target workload based on request volume. ================================================ FILE: content/docs/2.20/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.20/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. > ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md). You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.20/authentication-providers/aws-secret-manager.md ================================================ +++ title = "AWS Secret Manager" +++ You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified. ### Configuration ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: {key-in-k8s-secret} # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optionqal ``` ================================================ FILE: content/docs/2.20/authentication-providers/aws.md ================================================ +++ title = "AWS (IRSA) Pod Identity Webhook" +++ [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws roleArn: # Optional. identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set) ``` **Parameter list:** - `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload` - `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional) > ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported. ## How to use AWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags: 1. `--set podIdentity.aws.irsa.enabled=true` 2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}` You can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources. If you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role. **Regional STS endpoints** - If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace. - If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses). ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: namespace: annotations: eks.amazonaws.com/role-arn: # Required for regional STS endpoints (e.g. eu-west-1) eks.amazonaws.com/sts-regional-endpoints: "true" ``` ### When do you need regional STS endpoints? By default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`). Some regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`). If you see errors like: ``` AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity ``` while your IAM trust policy looks correct, you likely need to enable regional endpoints with: ```yaml annotations: eks.amazonaws.com/sts-regional-endpoints: "true" ``` 👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability. ## AssumeRole or AssumeRoleWithWebIdentity? This authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role. ## Setting up KEDA role and policy The [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`). ### Using KEDA role to access infrastructure Attach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sqs:GetQueueAttributes", "Resource": "arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE" } ] } ``` ### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity In this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity. This is an example of how role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { ... YOUR WORKLOAD TRUSTED RELATION ... }, { "Effect": "Allow", "Principal": { "Federated": "YOUR_OIDC_ARN" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "YOUR_OIDC:sub": "system:serviceaccount:keda:keda-operator", "YOUR_OIDC:aud": "sts.amazonaws.com" } } } ] } ``` ### Using KEDA role to assume workload role using AssumeRole In this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles. This is an example of how KEDA's role policy could look like: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_1:role/ROLE_NAME" ] }, { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::ACCOUNT_2:role/*" ] } ] } ``` This can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard. This policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role: ```json { "Version": "2012-10-17", "Statement": [ { // Your already existing relations "Sid": "", "Effect": "Allow", // ... }, { "Sid": "", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole" } ] } ``` #### Cross-account isolation with ExternalId In multi-tenant environments where a shared KEDA operator assumes roles in different accounts, you can enforce [confused deputy protection](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) by requiring an `ExternalId` in the workload role's trust policy. Add the `sts:ExternalId` condition to the workload role's trust policy: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "YOUR_UNIQUE_EXTERNAL_ID" } } } ] } ``` Then pass the `externalId` via `TriggerAuthentication.podIdentity.externalID` alongside `roleArn`: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: aws-trigger-auth namespace: my-namespace spec: podIdentity: externalID: "YOUR_UNIQUE_EXTERNAL_ID" roleArn: "arn:aws:iam::ACCOUNT:role/WORKLOAD_ROLE" ``` > ℹ️ **NOTE:** `externalId` is optional. If not set, KEDA calls `AssumeRole` without an ExternalId, which is the default behavior. `externalId` is only applied to `AssumeRole` — `AssumeRoleWithWebIdentity` does not accept an ExternalId parameter. ================================================ FILE: content/docs/2.20/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId from annotation on service-account. identityTenantId: # Optional. Default: TenantId from annotation on service-account. identityAuthorityHost: # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. Additionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ### Case 3 Similar to the previous scenario, you also have separate identities for your workloads but in different tenants: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A in Tenant A. - Workload B's identity with access to Service Bus B in Tenant B. In this case, you are overriding the default identity and tenant set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant. ================================================ FILE: content/docs/2.20/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.20/authentication-providers/bound-service-account-token.md ================================================ +++ title = "Bound service account token" +++ You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ## Permissions for KEDA to request service account tokens By default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster. To allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource. Here's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator namespace: my-namespace # Replace with the namespace of the service account rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - my-service-account # Replace with the name of the service account --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding namespace: my-namespace # Replace with the namespace of the service account roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator subjects: - kind: ServiceAccount name: keda-operator namespace: keda # Assuming the keda-operator service account is in the keda namespace ``` After applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API. ### Usage in keda-charts If you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example: ```yaml # values.yaml permissions: operator: restrict: serviceAccountTokenCreationRoles: - name: myServiceAccount namespace: myServiceAccountNamespace ``` This will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: keda-operator-token-creator-myServiceAccount namespace: myServiceAccountNamespace rules: - apiGroups: - "" resources: - serviceaccounts/token verbs: - create resourceNames: - myServiceAccount --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: keda-operator-token-creator-binding-myServiceAccount namespace: myServiceAccountNamespace roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: keda-operator-token-creator-myServiceAccount subjects: - kind: ServiceAccount name: keda-operator namespace: keda ``` ================================================ FILE: content/docs/2.20/authentication-providers/configmap.md ================================================ +++ title = "Config Map" +++ You can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use. ```yaml configMapTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-configmap-resource-name # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise. ================================================ FILE: content/docs/2.20/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.20/authentication-providers/file-path.md ================================================ +++ title = "File path" +++ You can read authentication parameters from files mounted in the KEDA operator pod using the `filePath` option. This feature requires the KEDA operator to be configured with a root path for file access. ## Security Constraints The `filePath` feature has important security constraints: - **Requires root path configuration** - The KEDA operator must be started with `--filepath-auth-root-path` to define the allowed directory - **Path validation** - All file paths are validated to ensure they resolve within the configured root path, preventing access to sensitive system files like service account tokens - **Relative paths** - The `filePath` in `ClusterTriggerAuthentication` is treated as a relative path under the configured root path ## Operator Configuration The KEDA operator requires a command-line argument to enable file-based authentication: ```bash --filepath-auth-root-path=/path/to/allowed/files ``` This path should point to a directory where credential files are mounted. The operator will only read files from within this directory. ## Example First, ensure the KEDA operator has the root path configured. Then create a `ClusterTriggerAuthentication` referencing files: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: file-based-auth spec: filePath: - parameter: apiKey # Required - Defined by the scale trigger path: credentials/api-key # Required - Path relative to filepath-auth-root-path ``` **Assumptions:** - The path is relative to the `--filepath-auth-root-path` configured for the KEDA operator - The credential file exists at `{filepath-auth-root-path}/credentials/api-key` - The file contains the raw credential value (not JSON encoded) - The file path should match the actual file name, including any extension if present (e.g., `credentials/api-key.txt` if the file is named `api-key.txt`) ================================================ FILE: content/docs/2.20/authentication-providers/gcp-secret-manager.md ================================================ +++ title = "GCP Secret Manager" +++ You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Steps to create the IAM Service Account Kubernetes secret - Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. - Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor. - Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account: ```shell gcloud iam service-accounts keys create KEY_FILE \ --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com ``` Replace the following: KEY_FILE: the file path to a new output file for the private key in your local machine. \ GSA_NAME: the name of your IAM service account. \ PROJECT_ID: your Google Cloud project ID. - Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource: ```shell kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE ``` Replace the following: NAME: name of the Kubernetes secret resource. \ KEY: Kubernetes secret key for the SA. \ KEY_FILE: the file path to the SA in your local machine. \ NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created. Now you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA. ================================================ FILE: content/docs/2.20/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to set up Workload Identity If you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.20/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method. There's multiple methods for authentication; For kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) or provide the serviceAccountName that can authenticate to kubernetes in the namespace of the ScaledObject/ScaledJob resource (usually `default`). If using serviceAccountName make sure to grant KEDA Operator `create serviceaccounts/token` permissions. This is set in the helm chart via `permissions.operator.restrict.allowAllServiceAccountTokenCreation=true` For token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. > Since version `1.5.0` Vault secrets backend **version 2** is supported. > The support for Vault secrets backend **version 1** was added on version `2.10`. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. Authenticate to vault via a supplied token serviceAccount: {path-to-service-account-file} # Optional. Authenticate to vault via JWT token in keda operator pod serviceAccountName: {service-account-name-for-auth} # Optional. Requires serviceaccounts/token create permissions. Authenticate to vault via JWT token from service account in ScaledObject/ScaledJob's namespace secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. type: {hashicorp-vault-secret-type} # Optional. Default to `""`. Allowed values: `secret`, `secretV2`, `pki` pkidata: {hashicorp-vault-secret-pkidata} # Optional. Data to be send with the secret if `hashicorp-vault-secret-type` is pki request commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional. altNames: {hashicorp-vault-secret-pkidata-altNames} # Optional. ipSans: {hashicorp-vault-secret-pkidata-ipSans} # Optional. uriSans: {hashicorp-vault-secret-pkidata-uriSans} # Optional. otherSans: {hashicorp-vault-secret-pkidata-otherSans} # Optional. ttl: {hashicorp-vault-secret-pkidata-ttl} # Optional. format: {hashicorp-vault-secret-pkidata-format} # Optional. ``` ### Example Vault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-mame} namespace: default spec: hashiCorpVault: address: {hashicorp-vault-address} authentication: token credential: token: {hashicorp-vault-token} secrets: - key: "ca_chain" parameter: "ca" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "private_key" parameter: "key" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} - key: "certificate" parameter: "cert" path: {hashicorp-vault-secret-path} type: pki pki_data: common_name: {hashicorp-vault-secret-pkidata-commonName} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: prometheus metadata: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: { trigger-authentication-mame } ``` ================================================ FILE: content/docs/2.20/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.20/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests. It’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup. ## How KEDA works KEDA monitors external event sources, like message queues, databases, or APIs, and automatically adjusts the number of running pods based on real-time demand. When events arrive, KEDA scales your workload up to handle the load. When things go quiet, it scales back down, all the way to zero if needed. It does this by working alongside Kubernetes' existing Horizontal Pod Autoscaler rather than replacing it. KEDA feeds the HPA with external metrics, extending it beyond CPU and memory to any event source you can connect to. The result is an application that responds to actual workload rather than just infrastructure signals. For batch workloads, KEDA takes a different approach: instead of scaling a running deployment up or down, it creates new Kubernetes Jobs in response to events, for example, one job per message in a queue. ## KEDA Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-new.png) KEDA runs three components inside the Kubernetes cluster, each with a distinct responsibility: * **keda-operator** watches KEDA resources like your ScaledObjects and manages the full HPA lifecycle. It is also directly responsible for scaling a workload between zero and one replica—bringing an idle deployment back to life when events arrive, or scaling it down to zero when there is nothing to process. * **keda-metrics-apiserver** exposes the external metrics (polled from event sources such as Kafka, RabbitMQ, Elasticsearch, or SQS) to the Kubernetes HPA via the Kubernetes API Server. The HPA queries these metrics to decide how many replicas are needed above one. * **keda-admission-webhooks** validate every KEDA resource like your ScaledObject at the moment it is applied, catching configuration mistakes, such as two ScaledObjects targeting the same deployment, before they cause problems at runtime. The scaling flow works in two complementary tracks: 1. **Zero-to-one and one-to-zero scaling** is handled directly by the keda-operator. When an event source becomes active, the operator brings the deployment up from zero replicas; when it goes idle again, the operator scales it back down to zero. 2. **One-to-N and N-to-one scaling** is delegated to the Horizontal Pod Autoscaler. The keda-operator creates and manages the HPA resource; the HPA queries external metrics through the Kubernetes API Server (served by the keda-metrics-apiserver), and adjusts the number of running pods accordingly. The ReplicaSet inside the Deployment translates the desired replica count set by both tracks into actual running pods. ## KEDA Custom Resources (CRDs) KEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior: * **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works. * **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics. * **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials. These CRDs give you control over scaling while keeping your apps secure and responsive to demand. ## Scaling Deployments, StatefulSets, and Custom Resources KEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs. ### Scaling Deployments and StatefulSets With KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand. Deployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand. > Note: When using CPU or Memory triggers, the metric flow is different. KEDA still creates and manages the HPA, but the HPA fetches CPU and Memory data directly from the Kubernetes `metrics-server`, not via the `keda-metrics-apiserver`. As a result, scale-to-zero is not supported with CPU or Memory triggers: without running pods, there are no metrics to observe, so KEDA has no signal to scale back up from zero. ### Scaling Custom Resources KEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically. ### Scaling Jobs KEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed. ### Authentication KEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe. ### External Scalers KEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly. ### Consuming Raw Scaler Metrics Externally KEDA also allows consuming the internal metrics (coming from internal or external scalers) to interested 3rd parties. This feature is exposed using gRPC server stream API and needs to be first enabled by setting `RAW_METRICS_GRPC_PROTOCOL` to "`enabled`". Then one can subscribe to a metric identified by ScaledObject/ScaledJob name, namespace and trigger name using any gRPC client (example with [grpcurl](https://github.com/kedacore/keda/pull/7093#issuecomment-3333530716)). You can control when raw metrics are sent using the `RAW_METRICS_MODE` environment variable: * `all` or `""` (empty): Sends all raw metrics, both when the metrics server requests them (HPA) and during the regular polling interval of each ScaledObject or ScaledJob. This is the default behavior. * `hpa`: Sends raw metrics only when the Kubernetes metrics server explicitly requests metrics for a ScaledObject. This means metrics are sent in response to HPA queries, not on a regular schedule. * `pollinginterval`: Sends raw metrics only during the polling interval of each ScaledObject or ScaledJob. In this mode, metrics are pushed out at each polling cycle, regardless of HPA requests. * Any unknown value will default to the `all` mode. ================================================ FILE: content/docs/2.20/concepts/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Automatically validate resource changes to prevent misconfiguration and enforce best practices" weight = 600 +++ There are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors. Some errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below. ### Prevention Rules KEDA will block all incoming changes to `ScaledObject` that don't match these rules: - The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA). - CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.** - In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name) - The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics. KEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules: - The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.) > NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation ================================================ FILE: content/docs/2.20/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject filePath: # Optional. Define only for ClusterTriggerAuthentication; not supported for TriggerAuthentication. - parameter: {scaledObject-parameter-name} # Required. path: {relative-path-to-file} # Required. Relative to --filepath-auth-root-path. hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/). ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### File(s) > **Note:** This feature requires the KEDA operator to be configured with `--filepath-auth-root-path`. You can read authentication parameters from files mounted in the KEDA operator pod. This is useful when credentials are provided via init containers or sidecars that write to a shared volume. The `filePath` option is only available for `ClusterTriggerAuthentication`, not for namespaced `TriggerAuthentication`. ```yaml filePath: # Optional. - parameter: apiKey # Required - Defined by the scale trigger path: credentials/api-key # Required - Path relative to filepath-auth-root-path ``` **Security constraints:** - The path is validated to ensure it resolves within the configured `--filepath-auth-root-path` - Access to sensitive paths like `/var/run/secrets/kubernetes.io/serviceaccount/` is blocked - Only `ClusterTriggerAuthentication` can use this authentication method **Assumptions:** - The KEDA operator must be started with `--filepath-auth-root-path=/path/to/allowed/files` - The credential file exists at `{filepath-auth-root-path}/{path}` - The file contains the raw credential value ### Bound service account token(s) You can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account. ```yaml boundServiceAccountToken: # Optional. - parameter: connectionString # Required - Defined by the scale trigger serviceAccountName: my-service-account # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### GCP Secret Manager secret(s) You can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key. The `secrets` list defines the mapping between the secret and the authentication parameter. GCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`. ```yaml gcpSecretManager: # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. id: {secret-manager-secret-name} # Required. version: {secret-manager-secret-name} # Optional. podIdentity: # Optional. provider: gcp # Required. credentials: # Optional. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-gcp-iam-sa-secret} # Required. key: {key-within-the-secret} # Required. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure-workload | aws | aws-eks | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. roleArn: # Optional. Only used by aws provider. identityOwner: keda|workload # Optional. Only used by aws provider. ``` #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` Setting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities. ### Aws Secret Manager(s) You can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification. The `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS. The `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`. - **accessKey:** Configuration for the AWS access key. - **secretAccessKey:** Configuration for the AWS secret access key. The `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified. The `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified. ```yaml awsSecretManager: podIdentity: # Optional. provider: aws # Required. credentials: # Optional. accessKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_ACCESS_KEY_ID # Required. accessSecretKey: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-aws-credentials} # Required. key: AWS_SECRET_ACCESS_KEY # Required. region: {aws-region} # Optional. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {aws-secret-name} # Required. version: {aws-secret-version} # Optional. secretKey: {aws-secret-key} # Optional. ``` #### AWS Pod Identity Webhook for AWS [**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws # Optional. Default: none roleArn: # Optional. identityOwner: keda|workload # Optional. ``` #### AWS EKS Pod Identity Webhook > [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343) [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.20/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.20/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ This page describes the deployment scaling behavior of KEDA. # Specification See the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below. # Scaling objects ## Scaling Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ## Scaling Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). # Features ## Caching Metrics This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval. Enabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service. This feature is not supported for `cpu`, `memory` or `cron` scaler. ## Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" autoscaling.keda.sh/paused: "true" ``` The presence of these annotations will pause autoscaling no matter what number of replicas is provided. The annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: ""` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number. Typically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling. To unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`. Additionally, we provide the ability to temporarily pause scale in on a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/paused-scale-in: "true" ``` When the annotation is set, KEDA will update the generated HPA to disable scale in (via setting the HPA's Scale Down Select Policy to Disabled) and if the service has scale to zero configured, will block scale to zero. When the annotation is unset, the scale down behavior on the HPA will be restored to its original configuration and, if configured, scale to zero will be unblocked. Conversely, we provide the ability to temporarily pause scale out on a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/paused-scale-out: "true" ``` When the annotation is set, KEDA will update the generated HPA to disable scale out (via setting the HPA's Scale Up Select Policy to Disabled) and if the service has scale to zero configured, will block scale from zero. When the annotation is unset, the scale up behavior on the HPA will be restored to its original configuration and, if configured, scale up from zero will be unblocked. If you want disable scaling in both directions, we recommend you use the `autoscaling.keda.sh/paused` as that will stop the scale loop and paused queries against the ScaledObject's configured scaler. ## Scaling Modifiers **Example: compose average value** ```yaml advanced: scalingModifiers: formula: "(trig_one + trig_two)/2" target: "2" activationTarget: "2" metricType: "AverageValue" ... triggers: - type: kubernetes-workload name: trig_one metadata: podSelector: 'pod=workload-test' - type: metrics-api name: trig_two metadata: url: "https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423" valueLocation: "tasks" ``` Formula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on. **Example: activationTarget** ```yaml advanced: scalingModifiers: activationTarget: "2" ``` If the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed. **Example: ternary operator** ```yaml advanced: scalingModifiers: formula: "trig_one > 2 ? trig_one + trig_two : 1" ``` If metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1. **Example: count function** ```yaml advanced: scalingModifiers: formula: "count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0" ``` If at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0 **Example: nested conditions and operators** ```yaml advanced: scalingModifiers: formula: "trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0" ``` Conditions can be used within another condition as well. If value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0. Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast. ## Activating and Scaling thresholds KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Forcing Activation We provide the ability to temporarily force the activation of a scale target: ```yaml metadata: annotations: autoscaling.keda.sh/force-activation: "true" ``` When the annotation is set, KEDA will treat all configured scalers as active. If the scalers were previously not active, KEDA will scale the service up from 0. When the annotation is subsequently unset, the state of the scaler activation will revert to being computed from the state of the scaler metrics. ## Transferring ownership of an existing HPA If your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject: ```yaml metadata: annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" spec: advanced: horizontalPodAutoscalerConfig: name: {name-of-hpa-resource} ``` > ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage. ## Disabling validations on an existing HPA You are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**. ```yaml metadata: annotations: validations.keda.sh/hpa-ownership: "true" ``` ### Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. #### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. #### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](./scaling-jobs). ## Excluding labels from being propagated to the HPA You can exclude specific labels from being propagated to the generated HPA object by using the `scaledobject.keda.sh/hpa-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded. ```yaml metadata: annotations: scaledobject.keda.sh/hpa-excluded-labels: "foo.bar/environment,foo.bar/version" labels: team: backend foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5 foo.bar/version: "1" ================================================ FILE: content/docs/2.20/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ This page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below. # Overview As an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` # Pausing autoscaling It can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads. This is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling. You can pause autoscaling by adding this annotation to your `ScaledJob` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused: true ``` To reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`. ```yaml metadata: annotations: autoscaling.keda.sh/paused: false ``` ## Example An example configuration for autoscaling jobs using a RabbitMQ scaler is given below. ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` # Excluding labels from being propagated to the Job You can exclude specific labels from being propagated to the generated Job object by using the `scaledjob.keda.sh/job-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded. ```yaml metadata: annotations: scaledjob.keda.sh/job-excluded-labels: "foo.bar/environment,foo.bar/version" labels: team: backend foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5 foo.bar/version: "1" ================================================ FILE: content/docs/2.20/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.20/deploy.md ================================================ +++ title = "Deploying KEDA" +++ KEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization. Using **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster. Each method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment. > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.30 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Prerequisites To deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features. If you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease. ### Installing 1. To deploy KEDA using Helm, first add the official KEDA Helm repository: ```sh helm repo add kedacore https://kedacore.github.io/charts helm repo update ``` 2. Install `keda` by running: **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods: ```sh kubectl get pods -n keda ``` To deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps: 1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version. 2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions: ```sh kubectl apply -f keda-2.xx.x-crds.yaml ``` Replace `2.xx.x` with the specific version number you downloaded. By deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process. > 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues. Deploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments. ### Uninstalling To uninstall KEDA, use the following Helm command: ```sh helm uninstall keda –namespace keda ``` This command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run: ```sh kubectl delete namespace keda ``` Uninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version. You can remove finalizers with the following command: ```sh kubectl patch scaledobject -p '{"metadata":{"finalizers":null}}' --type=merge kubectl patch scaledjob -p '{"metadata":{"finalizers":null}}' --type=merge ``` Replace \<*resource-name*\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster. ## Deploying with Operator Hub {#operatorhub} ### Prerequisites Before deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access. If you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub. ### Installing To deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed. Search for "KEDA" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace. 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) Using Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment. > 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository: > > [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator) > > This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments. > > For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful: > > \- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator. > > \- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster. > > \- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project. ### Uninstalling To uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster. If you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks. ## Deploying KEDA using the YAML files {#yaml} ### Prerequisites Before deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster. ### Installing Once the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command: ```sh # Including admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml # Without admission webhooks kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0-core.yaml ``` Alternatively you can download the file and deploy it from the local path: ```sh # Including admission webhooks kubectl apply --server-side -f keda-2.20.0.yaml # Without admission webhooks kubectl apply --server-side -f keda-2.20.0-core.yaml ``` The `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740). > 💡 **NOTE:** If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally: > > ```sh > git clone https://github.com/kedacore/keda && cd keda > > VERSION=2.20.0 make deploy > ``` > > This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization. After applying the YAML, verify the deployment by checking the KEDA namespace: ```sh kubectl get pods -n keda ``` Deploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates. ### Uninstalling If you installed KEDA using the released YAML files, you can uninstall it by running the following commands: ```sh # Including admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml # Without admission webhooks kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0-core.yaml ``` If you downloaded the files locally, uninstall with: ```sh # Including admission webhooks kubectl delete -f keda-2.20.0.yaml # Without admission webhooks kubectl delete -f keda-2.20.0-core.yaml ``` For users who cloned the KEDA GitHub repository, navigate to the cloned directory and use: ```sh VERSION=2.20.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Prerequisites Before deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`). Additionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons: * **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration. * **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation. ### Installing To install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on. 1. Enable Helm and DNS Add-ons (if not already enabled): ```sh microk8s enable dns helm3use ``` 2. Add the KEDA Helm Repository: ```sh microk8s helm3 repo add kedacore https://kedacore.github.io/charts microk8s helm3 repo update ``` 3. Install KEDA Using Helm. Deploy KEDA into your MicroK8s cluster by running: ```sh microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace ``` 4. Verify the Installation. Check that KEDA is running by listing the pods in the keda namespace: ```sh microk8s kubectl get pods -n keda ``` This approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development. ### Uninstalling To uninstall KEDA from your MicroK8s environment, disable the KEDA add-on: ```sh microk8s disable keda ``` This command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation. If you deployed KEDA using Helm, uninstall it with: ```sh microk8s helm3 uninstall keda --namespace keda ``` After running these commands, KEDA will be fully removed from your MicroK8s setup. ## Getting Started with KEDA: A Simple Example To help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This "Hello KEDA" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality. Before starting, ensure you have the following: * **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service. * **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster. * **KEDA Installed**: KEDA should be installed in your cluster. ### Step 1: Deploy a Sample Application We'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server. 1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: http-app spec: replicas: 1 selector: matchLabels: app: http-app template: metadata: labels: app: http-app spec: containers: - name: http-app image: hashicorp/http-echo args: - "-text=Hello, KEDA!" ports: - containerPort: 5678 ``` 2. **Apply the Deployment**: Run the following command to create the deployment: ```sh kubectl apply -f deployment.yaml ``` ### Step 2: Expose the Application To access the application, we'll create a Service. 1. **Create a Service Manifest**: Save the following YAML as `service.yaml`: ```yaml apiVersion: v1 kind: Service metadata: name: http-app-service spec: selector: app: http-app ports: - protocol: TCP port: 80 targetPort: 5678 type: LoadBalancer ``` 2. **Apply the Service**: Run the following command to create the service: ```sh kubectl apply -f service.yaml ``` 3. **Retrieve the External IP**: After a few moments, retrieve the external IP address: ```sh kubectl get service http-app-service ``` ### Step 3: Create a ScaledObject We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. 1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-app-scaledobject spec: scaleTargetRef: name: http-app minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: prometheus metadata: serverAddress: http://prometheus-server.default.svc.cluster.local:9090 threshold: '5' query: sum(rate(http_requests_total[1m])) ``` > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed. 2. **Apply the ScaledObject**: Run the following command to create the ScaledObject: ```sh kubectl apply -f scaledobject.yaml ``` ### Step 4: Test the Scaling Behavior We'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates. To observe KEDA's scaling in action: 1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP: ```sh hey -z 1m -c 10 http:// ``` Replace `` with the external IP address obtained earlier. 2. **Monitor Scaling:** Run the following command to watch the scaling behavior: ```sh kubectl get pods -w ``` You should see the number of pods increase as the load increases and decrease when the load subsides. ### Cleanup After completing the exercise, clean up the resources: ```sh kubectl delete -f scaledobject.yaml kubectl delete -f service.yaml kubectl delete -f deployment.yaml ``` This example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events. ================================================ FILE: content/docs/2.20/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.20/integrations/istio-integration.md ================================================ +++ title = "KEDA Integration with Istio" description = "Guidance for running KEDA along with Istio in your cluster" availability = "v2.14+" project = "Istio" +++ ## Overview Integrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements. This can be considered as workaround, however it's perfectly valid from the security standpoint. Keda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies. ## Background In some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied. ### Requirements - Istio version >= 1.18.* - Kubernetes cluster with KEDA installed ### Example configuration `values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml) ``` ... podAnnotations: # -- Pod annotations for KEDA operator keda: traffic.sidecar.istio.io/excludeInboundPorts: "9666" traffic.sidecar.istio.io/excludeOutboundPorts: "9443,6443" # -- Pod annotations for KEDA Metrics Adapter metricsAdapter: traffic.sidecar.istio.io/excludeInboundPorts: "6443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,9443" # -- Pod annotations for KEDA Admission webhooks webhooks: traffic.sidecar.istio.io/excludeInboundPorts: "9443" traffic.sidecar.istio.io/excludeOutboundPorts: "9666,6443" ... ``` *Check your respective ports set correctly for each component.* ### Applying the Annotations - Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations. - Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster. - Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks. ### References For more information on the annotations used, refer to the Istio documentation on traffic management. Existing troubleshooting guide for KEDA with Istio. ### Conclusion By applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services. If you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support. ================================================ FILE: content/docs/2.20/integrations/opentelemetry.md ================================================ +++ title= "Integrate with OpenTelemetry Collector (Experimental)" description= "Detail of integrating OpenTelemetry Collector in KEDA" availability = "v2.12+" project = "OpenTelemetry" +++ ## Push Metrics to OpenTelemetry Collector (Experimental) ### Operator The KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: ``` apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator ... containers: - name: keda-operator image: ghcr.io/kedacore/keda:latest command: - /keda args: --enable-opentelemetry-metrics=true ... ... env: - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://opentelemetry-collector.default.svc.cluster.local:4318" ``` The following metrics are being gathered: | Metric | Description | | ------ | ----------- | | `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. | | `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). | | `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). | | `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. | | `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. | | `keda.scaler.errors` | The number of errors that have occurred for each scaler. | | `keda.scaler.errors.total` | The total number of errors encountered for all scalers. | | `keda.scaler.empty.upstream.responses` | The number of times a scaler query returned an empty result from its upstream source, such as a Prometheus query returning no results. | | `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. | | `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. | | `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.registered.count` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | | `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. | | `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. | #### Deprecated metrics The following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16. | `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. | | `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). | | `keda.trigger.totals` | Total number of triggers per trigger type. | | `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. | ================================================ FILE: content/docs/2.20/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. - `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). - `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). - `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler. - `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler. - `keda_scaler_empty_upstream_responses_total` - The number of times a scaler returned an empty response from its upstream source (e.g. a Prometheus query returning no results). - `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject. - `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob. - `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator. - `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator. - `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. - `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. - `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue. - `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server. - `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure. - `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server. - `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server. - `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). > Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed. ### Admission Webhooks The KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations. - `keda_webhook_scaled_object_validation_errors` - The number of validation errors. ### Metrics Server The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client. - `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure. - `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client. - `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client. - `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). - Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/) ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaledJob - scaler - metric ================================================ FILE: content/docs/2.20/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.20/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance and requirements for operating KEDA" weight = 1 +++ We provide guidance and requirements around various areas to operate KEDA: - [Admission Webhooks](./admission-webhooks) - [Cluster](./cluster) - [Kubernetes Events](../reference/events) - [KEDA Metrics Server](./metrics-server) - [Security](./security) ================================================ FILE: content/docs/2.20/operate/admission-webhooks.md ================================================ +++ title = "Admission Webhooks" description = "Admission webhooks configurations guidance" weight = 100 +++ ## Validation Enforcement By default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required. In particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `"false"`. Be cautious when doing so as it exposes the system to potential risks. ### Cache Miss with Fallback to Direct Client for ScaledObject When validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`: ``` --cache-miss-to-direct-client=true ``` This will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API. ## Custom Validations using Kubernetes ValidatingAdmissionPolicy > ⚠️ FEATURE STATE: Kubernetes v1.30 [stable] Kubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/). Here is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10): ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-keda-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["keda.sh"] apiVersions: ["v1alpha1"] operations: ["CREATE", "UPDATE"] resources: ["scaledobjects"] validations: - expression: "object.spec.maxReplicaCount <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-keda-replicas-binding.example.com" spec: policyName: "limit-keda-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` Since KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas: ```yaml apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-apps-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] operations: ["CREATE", "UPDATE"] resources: ["deployments", "replicasets"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "limit-hpa-replicas.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["autoscaling"] apiVersions: ["v2"] operations: ["CREATE", "UPDATE"] resources: ["horizontalpodautoscalers"] validations: - expression: "object.spec.replicas <= 10" message: "The maximum allowed number of pod replicas is 10." --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-apps-replicas-binding.example.com" spec: policyName: "limit-apps-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default --- apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "limit-hpa-replicas-binding.example.com" spec: policyName: "limit-hpa-replicas.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: kubernetes.io/metadata.name: default ``` ================================================ FILE: content/docs/2.20/operate/cloud-events.md ================================================ +++ title = "CloudEvent Support" description = "Experimental support for cloud events" weight = 100 +++ ## Subscribing to events with `CloudEventSource` `CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink. > 📝 When a CloudEventSource resource is created, KEDA continues to emit Kubernetes Events and will additionally emit CloudEvents for the supported event types listed in this document. Here is a the schema of the `CloudEventSource` CRD: ```yaml apiVersion: eventing.keda.sh/v1alpha1 kind: CloudEventSource metadata: name: {cloud-event-name} spec: clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set. authenticationRef: name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster destination: http: uri: http://foo.bar azureEventGridTopic: endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` In general, an event emitted by KEDA would fundamentally come down to the following structure: ```json { "specversion" : "1.0", "type" : "com.cloudeventsource.keda", "source" : "/{cluster-name}/{keda-namespace}/keda", "subject" : "/{cluster-name}/{namespace}/{object-type}/{object-name}", "id" : "", "time" : "2018-04-05T17:31:00Z", "datacontenttype" : "application/json", "data" : { "reason":"", "message":"" } } ``` ## Event Sinks There will be multiple types of destination to emit KEDA events to. Here is an overview of the supported destinations: - [HTTP endpoint](#http-endpoint). - [Azure Event Grid endpoint](#azure-event-grid). ### HTTP endpoint ```yaml destination: http: uri: http://foo.bar #An http endpoint that can receive cloudevent ``` ### Azure Event Grid ```yaml destination: azureEventGrid: endpoint: foo.bar #endpoint from AzureEventGrid Topic ``` Authentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`. Here is an overview of the supported authentication types: #### Connection String Authentication - `accessKey` - Access key string for the Azure Event Grid connection auth. #### Pod identity based authentication [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` ## Event Filter You can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink. ```yaml eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. includedEventTypes: #Optional. Only events in this section will be emitted. - keda.scaledobject.failed.v1 excludedEventTypes: #Optional. Events in this section will not be emitted. - keda.scaledobject.ready.v1 ``` ## Supported Event List | Event Type | Scenario Description | |--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------| | `keda.scaledobject.ready.v1` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails | | `keda.scaledobject.removed.v1` | When a ScaledObject is deleted | | `keda.scaledobject.paused.v1` | When a ScaledObject is paused | | `keda.scaledobject.unpaused.v1` | When a ScaledObject is unpaused | | `keda.scaledjob.ready.v1` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `keda.scaledjob.failed.v1` | If the check validation for a ScaledJob fails | | `keda.scaledjob.removed.v1` | When a ScaledJob is deleted | | `keda.scaledjob.paused.v1` | When a ScaledJob is paused | | `keda.scaledjob.unpaused.v1` | When a ScaledJob is unpaused | | `keda.scaledjob.rolloutcleanup.started.v1` | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob | | `keda.scaledjob.rolloutcleanup.completed.v1` | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob | | `keda.scaledjob.rolloutcleanup.failed.v1` | When KEDA fails to delete a Job owned by the previous version of a ScaledJob | | `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created | | `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | | `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted | | `keda.authentication.clustertriggerauthentication.created.v1` | On the first time a ClusterTriggerAuthentication is created | | `keda.authentication.clustertriggerauthentication.updated.v1` | When a ClusterTriggerAuthentication is updated | | `keda.authentication.clustertriggerauthentication.removed.v1` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.20/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ----- | ------------- | | v2.20 | TBD | | v2.19 | v1.32 - v1.34 | | v2.18 | v1.31 - v1.33 | | v2.17 | v1.30 - v1.32 | | v2.16 | v1.29 - v1.31 | | v2.15 | v1.28 - v1.30 | | v2.14 | v1.27 - v1.29 | | v2.13 | v1.27 - v1.29 | | v2.12 | v1.26 - v1.28 | | v2.11 | v1.25 - v1.27 | | v2.10 | v1.24 - v1.26 | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | ------------------ | ----------------------- | ----------------------------- | | Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 on the KEDA operator deployment to your desired timeout in milliseconds. > ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata. ## 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: ```yaml - 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. ```yaml - env: HTTP_PROXY: http://proxy.server:port HTTPS_PROXY: http://proxy.server:port NO_PROXY: 10.0.0.0/8 ``` ## HTTP TLS min version Our industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities. By default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`. For example: ```yaml - env: KEDA_HTTP_MIN_TLS_VERSION: TLS13 ``` The following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`. ## 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## gRPC Metrics Service Parameters The gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary: | Adapter Flag | Default Value | Description | | ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | metrics-service-address | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server | | metrics-service-grpc-authority | "" | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | ---------- | ------------- | ---------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | ## Configure Leader Election Like reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | ## Restrict the Namespaces KEDA is Watching By default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`. It accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces. When a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator. Example: ```yaml - env: WATCH_NAMESPACE: keda,production ``` ## Certificates used by KEDA Metrics Server To learn more please refer to [security section](./security#use-your-own-tls-certificates) ## Restrict Secret Access By default, KEDA requires adding `secrets` to the cluster role as following: ```yaml - 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: ```yaml 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`. ## Restrict Custom Resources As KEDA supports scaling any workload inside the cluster, there is a non restrictive RBAC rule applied to all the cluster ```yaml - apiGroups: - * resources: - */scale verbs: - get - list - patch - update - watch - apiGroups: - * resources: - * verbs: - get ``` However, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces as well as any workload type accross all the cluster. To limit this permissions, you can review and adapt the RBAC generated by KEDA based on your necessities to only grant those permissions that you intentionally want to grant. > Note: If you are using KEDA's helm chart, you can totally disable Custom Resources via `rbac.enabledCustomScaledRefKinds` or limit the current `*` setting only your needed resources via `rbac.scaledRefKinds`. > It is always recommended to review the final generated role for KEDA components to ensure no broad permissions are assigned if the Helm template was customized. To quickly verify typical cases like blocked access to secrets, any tool used to analyze K8s RBAC can be used (e.g. https://github.com/aquasecurity/kubectl-who-can). ## Logs KEDA uses zap to emit logs. The following flags can be used to configure logging behavior in both the metrics-apiserver and operator: - zap-encoder: Zap log encoding (one of `json` or `console`). Default is `console` - zap-log-level: Zap Level to configure the verbosity of logging. Can be one of `debug`, `info`, `error`, or any integer value > 0 which corresponds to custom debug levels of increasing verbosity". Default is `info`. - zap-time-encoding: Zap time encoding (one of `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano`), Defaults is `rfc3339`. ================================================ FILE: content/docs/2.20/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA (external metrics only): ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "externalmetrics", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] } ] } ``` In order to query a specific metric value, you also can do it using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.20/operate/schema.md ================================================ +++ title = "Schema" description = "Specification & generation of KEDA scalers' schema" weight = 100 +++ ## Scaler Schema KEDA provides a separate scaler's schema for third-party usage ([scalers-metadata-schema.yaml](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.yaml)/[scalers-metadata-schema.json](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.json)). The schema file will keep updating according to the scaler's refactor. *Notice: The schema file still lacks some of the scalers. It will be completed once all scalers are refactored to use the new declarative scaler config. ## Specification Here is a the schema of the scalers: ``` kedaVersion: main schemaVersion: 1 scalers: - type: activemq parameters: - name: managementEndpoint type: string optional: true metadataVariableReadable: true - name: destinationName type: string optional: true metadataVariableReadable: true - name: brokerName type: string optional: true metadataVariableReadable: true - name: username type: string metadataVariableReadable: true envVariableReadable: true triggerAuthenticationVariableReadable: true - name: password type: string metadataVariableReadable: true envVariableReadable: true triggerAuthenticationVariableReadable: true - name: corsHeader type: string optional: true metadataVariableReadable: true - name: restAPITemplate type: string optional: true metadataVariableReadable: true - name: targetQueueSize type: string default: "10" metadataVariableReadable: true - name: activationTargetQueueSize type: string default: "0" metadataVariableReadable: true - type: apache-kafka parameters: - name: bootstrapServers ... ``` **Metadata field's property detail:** | Property | Description |--------------|------------ | name | the name of the field | type | type is the variable type of the field | optional | optional is a boolean that indicates if the field is optional | default | default is the default value of the field | allowedValue | allowedValue is a list of allowed values for the field | deprecated | deprecated is a string that indicates if the field is deprecated | deprecatedAnnounce | deprecatedAnnounce is a string that indicates the deprecation message | separator | separator is the symbol that separates the value of the field if the value is a list string | exclusiveSet | exclusiveSet is a list of fields that are exclusive with the field | rangeSeparator | rangeSeparator is the symbol that indicates the range of the field | metadataVariableReadable | metadataVariableReadable is a boolean that indicates if the field can be read from the environment | envVariableReadable | envVariableReadable is a boolean that indicates if the field can be read from the environment | triggerAuthenticationVariableReadable | triggerAuthenticationVariableReadable is a boolean that indicates if the field can be read from the trigger authentication ## Generation There are two ways to generate scaler schemas: 1. Run the GO file in the schema folder directly ``` go run schema/generate_scaler_schema.go parameters: --keda-version string Set the version of current KEDA in schema. (default "1.0") --kubeconfig string Paths to a kubeconfig. Only required if out-of-cluster. --output-file-path string scaler-metadata-schemas.yaml output file path. (default "./") --scalers-builder-file buildScaler The file that exists buildScaler func. (default "../pkg/scaling/scalers_builder.go") --scalers-files-dir string The directory that exists all scalers' files. (default "../pkg/scalers") --specify-scaler string Specify scaler name. ``` 2. Use makefile ``` make generate-scaler-schemas env variables: OUTPUT_FILE_PATH scaler-metadata-schemas.yaml output file path. (default "./") SCALERS_BUILDER_FILE The file that exists buildScaler func. (default "../pkg/scaling/scalers_builder.go") SCALERS_FILES_DIR The directory that exists all scalers' files. (default "../pkg/scalers") ``` SCALERS_BUILDER_FILE ?= "pkg/scaling/scalers_builder.go" SCALERS_FILES_DIR ?= "pkg/scalers" OUTPUT_FILE_PATH ?= "schema/" ================================================ FILE: content/docs/2.20/operate/security.md ================================================ +++ title = "Security" description = "Guidance to configure security options" weight = 100 +++ ## Use your own TLS Certificates KEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA. The KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names: ``` -> eg. keda-operator .svc -> eg. keda-operator.svc .svc. -> eg. keda-operator.svc.cluster.local ``` To change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain="my-domain"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value. While this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). Certificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too). Additionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources. Example use case: - When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources. 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, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components. ## Register your own CA in KEDA Operator Trusted Store There are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure. To overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory. Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`. ================================================ FILE: content/docs/2.20/reference/_index.md ================================================ +++ title = "Reference" weight = 2 +++ Reference information for the KEDA autoscaler. - [ScaledObject specification](./scaledobject-spec) - [ScaledJob specification](./scaledjob-spec) - [Kubernetes Events](./events) - [Firewall requirements](../operate/cluster#firewall) - [FAQ](./faq.md) - [Glossary](./glossary.md) ================================================ FILE: content/docs/2.20/reference/events.md ================================================ +++ title = "Events reference" description = "Kubernetes Events emitted by KEDA" weight = 2500 +++ KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/): | Event | Type | Description | |---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectUpdateFailed` | `Warning` | When KEDA fails to update status for a ScaledObject | | `ScaledJobUpdateFailed` | `Warning` | When KEDA fails to update status for a ScaledJob | | `ScaledObjectPaused` | `Normal` | When a ScaledObject is paused | | `ScaledObjectUnpaused` | `Normal` | When a ScaledObject is unpaused | | `ScaledObjectFallbackActivated` | `Normal` | When a ScaledObject fallback becomes active | | `ScaledObjectFallbackDeactivated` | `Normal` | When a ScaledObject fallback becomes inactive | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `ScaledJobPaused` | `Normal` | When a ScaledJob is paused | | `ScaledJobUnpaused` | `Normal` | When a ScaledJob is unpaused | | `ScaledJobPauseFailed` | `Warning` | When KEDA fails to pause a ScaledJob | | `ScaledJobRolloutCleanupStarted` | `Normal` | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob | | `ScaledJobRolloutCleanupCompleted` | `Normal` | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob | | `ScaledJobRolloutCleanupFailed` | `Warning` | When KEDA fails to delete a Job owned by the previous version of a ScaledJob | | `ScaledJobActive` | `Normal` | When a ScaledJob becomes active (triggers are active and scaling is performed) | | `ScaledJobInactive` | `Normal` | When a ScaledJob becomes inactive (triggers are not active and scaling is not performed) | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAMetricSourceFailed` | `Warning` | When a scaler fails as a metric source for custom formula | | `KEDAScalerInfo` | `Normal` | When a Scaler contains deprecated field | | `KEDAScalerInfo` | `Warning` | When a Scaler contains unexpected parameter (disabled by default, enable with `KEDA_CHECK_UNEXPECTED_SCALERS_PARAMS`) | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `KEDAJobCreateFailed` | `Warning` | When KEDA fails to create a Job for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationUpdated` | `Normal` | When a TriggerAuthentication is updated | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationUpdated` | `Normal` | When a ClusterTriggerAuthentication is updated | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.20/reference/faq.md ================================================ +++ title = "FAQ" weight = 2000 +++ {{< faq20 versionData="faq2_19" >}} ================================================ FILE: content/docs/2.20/reference/glossary.md ================================================ +++ title = "Glossary" weight = 1000 +++ This document defines the various terms needed to understand the documentation and set up and use KEDA. ## Admission Webhook [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources. ## Agent A primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero. ## Cluster [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications. ## CRD Custom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior. ## Event A notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment. ## Event Source An external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler. ## Grafana An open-source monitoring platform that can visualize metrics collected by KEDA. ## gRPC Remote Procedure Calls (gRPC) gRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate. ## HPA Horizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments. ## KEDA Kubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics. ## Metric Measurement of an event source such as queue length or response lag that KEDA uses to determine scaling. ## OpenTelemetry An observability framework used by KEDA to instrument applications and collect metrics. ## Operator The core KEDA component that monitors metrics and scales workloads accordingly. ## Prometheus An open-source monitoring system that can scrape and store metrics from KEDA. ## Scaled Object A custom resource that defines how KEDA should scale a workload based on events. ## Scaled Job A custom resource KEDA uses to scale an application. ## Scaler A component that integrates KEDA with a specific event source to collect metrics. ## Stateful Set A Kubernetes workload with persistent data. KEDA can scale stateful sets. ## TLS Transport Layer Security. KEDA uses TLS to encrypt communications between KEDA components. ## Webhook An HTTP callback used to notify KEDA of events from external sources. [In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism. ================================================ FILE: content/docs/2.20/reference/scaledjob-spec.md ================================================ +++ title = "ScaledJob specification" weight = 4000 +++ ## Overview This specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} labels: my-label: {my-label-value} # Optional. ScaledJob labels are applied to child Jobs annotations: autoscaling.keda.sh/paused: true # Optional. Use to pause autoscaling of Jobs my-annotation: {my-annotation-value} # Optional. ScaledJob annotations are applied to child Jobs spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## jobTargetRef ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. ## successfulJobsHistoryLimit, failedJobsHistoryLimit ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. ## envSourceContainerName ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ## minReplicaCount ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | |--------------|-------------------|----------------------|-------------------|---------------------| | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. ## rollout ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. ## scalingStrategy ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). **eager** When adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible. For example, let's assume we configure a ScaledJob in a cluster as below: ```yaml ### # A job that runs for a minimum of 3 hours. ### pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: rabbitmq metadata: queueName: woker_queue hostFromEnv: RABBITMQ_URL mode: QueueLength value: "1" ``` We send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3. With the `default` scaling strategy, we are supposed to see the metrics changes in the following table: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 3 | If we switch to `eager`, the result becomes: | | initial | incoming 3 messages | after poll | incoming 3 messages | after poll | |-------------|---------|---------------------|------------|---------------------|------------| | queueLength | 0 | 3 | 3 | 6 | 6 | | runningJobs | 0 | 0 | 3 | 3 | 6 | We can identify the difference in their final states. You may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information. --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ### multipleScalersCalculation ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. ================================================ FILE: content/docs/2.20/reference/scaledobject-spec.md ================================================ +++ title = "ScaledObject specification" weight = 3000 +++ ## Overview This specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} annotations: scaledobject.keda.sh/transfer-hpa-ownership: "true" # Optional. Use to transfer an existing HPA ownership to this ScaledObject validations.keda.sh/hpa-ownership: "true" # Optional. Use to disable HPA ownership validation on this ScaledObject autoscaling.keda.sh/paused: "true" # Optional. Use to pause autoscaling of objects explicitly spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds initialCooldownPeriod: 0 # Optional. Default: 0 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: {kind-of-behavior} # Optional. Default: "static" advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ## scaleTargetRef ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject ## pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. When scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N. If you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly. ## cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) ## initialCooldownPeriod ```yaml initialCooldownPeriod: 120 # Optional. Default: 0 seconds ``` The delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration. This parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable. **Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.) ## idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). ## minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. ## maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. ## fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included behavior: "static" # Optional. Default: "static" ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. Fallback is supported for all triggers of both `Value` and `AverageValue` metric types, except CPU & memory triggers. It's also only supported by `ScaledObjects`, not `ScaledJobs`. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula for `AverageValue` metrics: ``` target metric value * fallback replicas ``` For `Value` metrics it's using the formula: ``` target metric value * fallback replicas / current ready replicas ``` These formulas offset the HPA's calculations and will cause it to scale the deployment to the specified number of fallback replicas. ## fallback.behavior The `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used. #### `static` behavior When `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'. #### `currentReplicas` behavior When using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'. #### `currentReplicasIfHigher` behavior When using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'. #### `currentReplicasIfLower` behavior When using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used. **Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'. ## advanced ### restoreToOriginalReplicaCount ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) ### horizontalPodAutoscalerConfig ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 tolerance: 0.1 # requires Kubernetes v1.33 or newer and feature gate "HPAConfigurableTolerance" ``` #### horizontalPodAutoscalerConfig.name The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` #### horizontalPodAutoscalerConfig.behavior Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. #### horizontalPodAutoscalerConfig.behavior tolerance As of Kubernetes v1.34 the `tolerance` field can be specified under the HPA behavior policy `scaleUp` and `scaleDown` sections. The field applies a tolerance thresholds for scaling decisions, allowing you to specify different behavior for scale-up and scale-down operations. This field was in alpha release under Kubernetes v1.33, which can be enabled through the Kubernetes `HPAConfigurableTolerance` feature gate. As of Kubernetes v1.34, this field has graduated to beta release and is specifiable by default. ### scalingModifiers If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined. ```yaml advanced: scalingModifiers: # Optional. Section to specify scaling modifiers target: {target-value-to-scale-on} # Mandatory. New target if metrics are anyhow composed together activationTarget: {activation-target-value-to-scale-on} # Optional. New activation target if metrics are anyhow composed together metricType: {metric-type-for-the-modifier} # Optional. Metric type to be used if metrics are anyhow composed together formula: {formula-for-fetched-metrics} # Mandatory. Formula for calculation ``` #### scalingModifiers.target `target` defines new target value to scale on for the composed metric. #### scalingModifiers.activationTarget `activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional). There is one important exception to the activation target for scaling modifiers and that is [external push scalers](../concepts/external-scalers). These scalers can implement `StreamIsActive` gRPC method which pushes activation status to KEDA directly, regardless of what the metric value and activation target is. #### scalingModifiers.metricType `metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional) #### scalingModifiers.formula `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). For examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md). ## triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](../scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional) - **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](../concepts/authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ================================================ FILE: content/docs/2.20/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.20/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.20/scalers/apache-kafka-go.md ================================================ +++ title = "Apache Kafka (Experimental)" availability = "v2.12+" maintainer = "Community" category = "Messaging" description = "Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "apache_kafka_scaler" +++ > **Notice:** > - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library. > - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. > - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication. > - This scaler has support for AWS MSK IAM based authentication. > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `apache-kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: apache-kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: false scaleToZeroOnInvalidOffset: false excludePersistentLag: false limitToPartitionsWithLag: false ensureEvenDistributionOfPartitions: false partitionLimitation: '1,2,10-20,31' tls: enable sasl: plaintext ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`. If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively. In case of SASL based authentication provide the `username` and `password`. For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) - `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) For authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### New `ensureEvenDistributionOfPartitions` property support When scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to. Consider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution. Below are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default. - For lag between `1 -> 10` we would be running `1` consumer - For lag between `11 -> 20` we would be running `2` consumer - For lag between `21 -> 50` we would be running `5` consumers - For lag higher than `51` we would be running `10` consumers ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.20/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true` > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' limitToPartitionsWithLag: 'false' ensureEvenDistributionOfPartitions: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' sasl: plaintext tls: enable unsafeSsl: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional) - `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence. - `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence. - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional) - `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `keytab` - Kerberos keytab. Either `password` or `keytab` is required in case of `gssapi`. (Optional) - `realm` - Kerberos realm. (Optional unless sasl mode is `gssapi`) - `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`) - `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided) - `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional) - `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **AWS MSK IAM Specific Configuration:** For authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### New `ensureEvenDistributionOfPartitions` property support When scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to. Consider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution. Below are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default. - For lag between `1 -> 10` we would be running `1` consumer - For lag between `11 -> 20` we would be running `2` consumer - For lag between `21 -> 50` we would be running `5` consumers - For lag higher than `51` we would be running `10` consumers ### Example #### Your kafka cluster has no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` #### Your kafka cluster turns on SASL/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: plaintext # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL OAuthbearer/TLS auth: ##### Method 1: `tls` and `sasl` are in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ##### Method 2: `tls` and `sasl` are in ScaledObject ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" oauthExtensions: "extension_logicalCluster=1,extension_identityPoolId=2" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: oauthExtensions name: keda-kafka-secrets key: oauthExtensions - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic tls: enable sasl: oauthbearer # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your kafka cluster turns on SASL/GSSAPI auth without TLS: ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes: - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/kerberos name: temp-kerberos-vol readOnly: false volumes.keda.extraVolumes - name: temp-kerberos-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in TriggerAuthentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "gssapi" tls: "disable" username: "admin" realm: keytab: kerberosConfig: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: tls name: keda-kafka-secrets key: tls - parameter: username name: keda-kafka-secrets key: username - parameter: realm name: keda-kafka-secrets key: realm - parameter: keytab name: keda-kafka-secrets key: keytab - parameter: kerberosConfig name: keda-kafka-secrets key: kerberosConfig --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` #### Your AWS MSK has IAM auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" saslTokenProvider: "aws_msk_iam" tls: "enable" awsAccessKeyID: awsSecretAccessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: saslTokenProvider name: keda-kafka-secrets key: saslTokenProvider - parameter: tls name: keda-kafka-secrets key: tls - parameter: awsAccessKeyID name: keda-kafka-secrets key: awsAccessKeyID - parameter: awsSecretAccessKey name: keda-kafka-secrets key: awsSecretAccessKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: apache-kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic awsRegion: us-east-1 # AWS region of your MSK cluster # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.20/scalers/arangodb.md ================================================ +++ title = "ArangoDB" availability = "v2.10+" maintainer = "Community" category = "Datastore" description = "Scale applications based on ArangoDB query result." go_file = "arangodb_scaler" +++ ### Trigger Specification This specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata: ```yaml triggers: - type: arangodb metadata: # Required fields: endpoints: "https://:8529,https://:8529" # Note: add one or more comma separated URL endpoints of all the coordinators query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} # Note: the query should return only a single numeric value in the JSON format {"value":} queryValue: '3' dbName: gradesheet collection: class # Optional fields: activationQueryValue: '3' connectionLimit: 13 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs ``` **Parameter list:** - `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter. - `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{"value":}`. - `dbName` - Name of the database. It can also be provided as an authentication parameter. - `collection` - Name of the collection. - `threshold` - A threshold that will define when scaling should occur. - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `connectionLimit` - Specify the max size of the active connection pool. (Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters ArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) Additionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: arangodb-deployment triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' activationQueryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} ``` Here is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-arangodb-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} serverID: "uDmcE-0Zd" authModes: "bearer" authenticationRef: name: keda-arangodb-creds ``` Here is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-arangodb-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-arangodb-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-arangodb-secret key: username - parameter: password name: keda-arangodb-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: arangodb-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: arangodb metadata: endpoints: https://:8529 queryValue: '3' dbName: gradesheet collection: class query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {"value":length} authModes: "basic" authenticationRef: name: keda-arangodb-creds ``` ================================================ FILE: content/docs/2.20/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" category = "Messaging" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. **TLS authentication:** - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - Password for the client certificate private key. (Optional, Required when `key` is encrypted) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ### Example with TLS (HTTPS with self-signed certificates) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8443" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" unsafeSsl: "true" # Skip certificate validation for self-signed certificates authenticationRef: name: trigger-auth-kedartemis ``` ### Example with mutual TLS (client certificates) ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis-tls namespace: kedartemis type: Opaque data: artemis-ca: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=" # Base64 encoded CA certificate artemis-cert: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=" # Base64 encoded client certificate artemis-key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi4uLgo=" # Base64 encoded client private key --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis-tls namespace: kedartemis spec: secretTargetRef: - parameter: ca name: kedartemis-tls key: artemis-ca - parameter: cert name: kedartemis-tls key: artemis-cert - parameter: key name: kedartemis-tls key: artemis-key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8443" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" authenticationRef: name: trigger-auth-kedartemis-tls ``` ================================================ FILE: content/docs/2.20/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Optional: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' # Optional: metricName metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Optional: ignoreNullValues ignoreNullValues: "false" # Required: region awsRegion: "eu-west-1" # Optional: Specify metric source AWS Account ID when using CloudWatch cross-account observability awsAccountId: "" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsAccountId` - Specify metric source AWS Account ID when using CloudWatch cross-account observability - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified) - `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). Supports all CloudWatch statistics including percentiles (e.g., `p95`, `p50`) and trimmed means (e.g., `tm99`, `tm95`). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response. If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional) > Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload. - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.20/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.20/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional: indexName indexName: "" # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}, ":filterValue" : {"S" : "hello world"}}' # Optional: filterExpression filterExpression: 'filterField = :filterValue' # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `indexName` - The index used by the DynamoDB Query. (Optional) - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `filterExpression` - the condition that specifies the filterExpression to be used by the Query action. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.20/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.20/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating "actual messages" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`. - `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional) - `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth) **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.20/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.20/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.20/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) > When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.20/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Optional (Default: false) unsafeSsl: "false" # Optional. Custom timeout for the HTTP client used in this scaler timeout: "1000" ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). - `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool) - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides ### Links - [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) - [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity) - [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity) ================================================ FILE: content/docs/2.20/scalers/azure-monitor.md ================================================ +++ title = "Azure Monitor" availability = "v1.3+" maintainer = "Microsoft" category = "Metrics" description = "Scale applications based on Azure Monitor metrics." go_file = "azure_monitor_scaler" +++ ### Trigger Specification This specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric. ```yaml triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" targetValue: "0.5" activationTargetValue: "3.5" activeDirectoryClientId: # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.20/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" category = "CI/CD" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" # Optional: Demands of jobs must exactly match the capabilities the trigger defines requireAllDemands: false # Optional: Require jobs to include specified demands, ignoring any extra ones requireAllDemandsAndIgnoreOthers: false # Optional: How many jobs to fetch for the pool in the API (default: 250) jobsToFetch: "{jobsToFetch}" # Optional: Whether to only fetch unfinished jobs from the API (default: false) fetchUnfinishedJobsOnly: false # Optional: Property to enable case-insensitive comparison of pipeline job demands (default: false) caseInsensitiveDemandsProcessing: false authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME". Mutually exclusive with `jobsToFetch`. - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` - `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API. Mutually exclusive with `parent` and `fetchUnfinishedJobsOnly`. (Default: `250`, Optional) - `fetchUnfinishedJobsOnly` - Whether to fetch only unfinished jobs from the Azure Pipeline API. Normally both finished, running and pending jobs are returned by the API. When this parameter is set to `true`, the API call is modified so that only running and pending jobs are returned from the API, which reduces the amount of returned jobs considerably. Mutually exclusive with `jobsToFetch`. (Default: `false`, Optional) - `caseInsensitiveDemandsProcessing` - Property to enable case-insensitive comparison of pipeline job demands. When this parameter is set to `true`, the demands check is case-insensitive. (Default: `false`, Optional) > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not use demands in your agent scaler then it scales based on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`. - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list. - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted. Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. However, as this an undocumented API, it possesses some unique quirks when calling it with different query parameters. For example, if the `$top` query parameter is given, the format of the returned JSON is changed in such a way that it is no longer possible for the scaler to find the matched agents; making it impossible to use with the `parent` property from the trigger metadata. Therefore making `jobsToFetch` mutually exclusive with `parent` in the trigger metadata. Additionally, the `$top` query parameter takes precedence over some other parameters like `completedRequestCount`. If the `$top` query parameter is given, finished jobs are included in the response even if `completedRequestCount=0` is given, although `completedRequestCount=0` would indicate that only pending and running jobs should be returned. Thus, `jobsToFetch` is also mutually exclusive with `fetchUnfinishedJobsOnly` in the trigger metadata. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ### Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ### Example for using pod identity authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.20/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ### Troubleshooting #### KEDA is unable to get queue information due to "invalid queue runtime properties: no CountDetails element" When KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus. Consider applying one of the following mitigations: - Scaling the Azure Service Bus namespace to a higher SKU, or use premium - Increase the polling interval of the ScaledObject/ScaledJob - Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics) ================================================ FILE: content/docs/2.20/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.20/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' queueLengthStrategy: all|visibleonly activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 # Optional queueLengthStrategy: "all" # or visibleonly. Default: all cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.20/scalers/beanstalkd.md ================================================ +++ title = "Beanstalkd" availability = "v2.16+" maintainer = "Community" description = "Scale applications based on beanstalkd queues" go_file = "beanstalkd_scaler" +++ ### Trigger Specification This specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue. ```yaml triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 includeDelayed: "false" tube: "default" activationValue: "10" value: "15" timeout: "30" ``` **Parameter list:** - `server` - Address of beanstalkd server `:`. If no port is specified then the scaler will default to `11300`. - `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted. - `tube` - Name of the tube to scale on. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set. - `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional) ### Authentication Parameters No authentication should be needed to connect to the beanstalkd server. ### Example #### Default tube with activation value Here the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'default' activationValue: "10" value: "20" ``` #### User-created tube with minimum replicas A minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: beanstalkd-scaledobject spec: scaleTargetRef: name: beanstalkd-consumer minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: beanstalkd metadata: server: beanstalkd.internal-namespace:11300 tube: 'scaling-tube' value: "5" includeDelayed: "true" ``` ================================================ FILE: content/docs/2.20/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to log in to the Cassandra instance. - `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional). - `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional) - `key` - Key path for client authentication. Mandatory if tls enabled. (Optional) ### Example with no TLS auth ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ### Example with TLS auth Since we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. ##### `sasl/gssapi` in manager.yaml If you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container. ``` volumeMounts: - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes: - name: temp-cassandra-vol emptyDir: medium: Memory ``` ##### `sasl/gssapi` in keda-charts If you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations. ``` volumes.keda.extraVolumeMounts - mountPath: /tmp/cassandra name: temp-cassandra-vol readOnly: false volumes.keda.extraVolumes - name: temp-cassandra-vol emptyDir: medium: Memory ``` Once we have the writable mount path set up for the certificates and keys. ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD tls: enable cert: key: ## Optional parameter ca ## ca: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password - parameter: tls name: cassandra-secrets key: tls - parameter: cert name: cassandra-secrets key: cert - parameter: key name: cassandra-secrets key: key ## Optional parameter ca ## - parameter: ca name: cassandra-secrets key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.20/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.20/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.20/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" category = "Scheduling" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be the same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale your deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do it the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.20/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). There are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately. ## Using the Datadog Cluster Agent (Experimental) With this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches. ### Deploy the Datadog Cluster Agent with enabled external metrics First, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA). If you are using Helm to deploy the Cluster Agent, set: * `clusterAgent.metricsProvider.enabled` to `true` * `clusterAgent.metricsProvider.registerAPIService` to `false` * `clusterAgent.metricsProvider.useDatadogMetrics` to `true` * `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}]` If you are using the Datadog Operator, add the following options to your `DatadogAgent` object: ``` apiVersion: datadoghq.com/v2alpha1 kind: DatadogAgent metadata: name: datadog spec: features: externalMetricsServer: enabled: true useDatadogMetrics: true registerAPIService: false override: clusterAgent: env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: "false"}] [...] ``` NOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later. ### Create a DatadogMetric object for each scaling query To use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: "true"` annotation, to ensure the Cluster Agent retrieves the query value. Example: ```yaml apiVersion: datadoghq.com/v1alpha1 kind: DatadogMetric metadata: annotations: external-metrics.datadoghq.com/always-active: "true" name: nginx-hits spec: query: sum:nginx.net.request_per_s{kube_deployment:nginx} ``` ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType metricUnavailableValue: "1.5" timeout: "10s" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional) - `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events. - `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events. - `targetValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) - `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. > 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as "no data" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA. ### Authentication The Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below: **Common to all authentication types** - `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional) - `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed. - `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern. - `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional) **Bearer authentication:** - `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated. ### Example ```yaml apiVersion: v1 kind: ConfigMap metadata: name: datadog-config namespace: my-project data: datadogNamespace: # Required: namespace where the Datadog Cluster Agent is deployed datadogMetricsService: # Required: Cluster Agent metrics server service name unsafeSsl: # Optional: set to "true" to skip SSL certificate validation authMode: # Required: authentication mode (bearer) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: datadog-cluster-agent-creds namespace: my-project spec: boundServiceAccountToken: - parameter: token serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io configMapTargetRef: - parameter: datadogNamespace name: datadog-config key: datadogNamespace - parameter: unsafeSsl name: datadog-config key: unsafeSsl - parameter: authMode name: datadog-config key: authMode - parameter: datadogMetricsService name: datadog-config key: datadogMetricsService --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx maxReplicaCount: 3 minReplicaCount: 1 pollingInterval: 60 triggers: - type: datadog metadata: useClusterAgentProxy: "true" datadogMetricName: "nginx-hits" datadogMetricNamespace: "default" targetValue: "2" type: "global" timeout: "10s" authenticationRef: name: datadog-cluster-agent-creds ``` ## Using the Datadog REST API ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API. ```yaml triggers: - type: datadog metricType: Value metadata: useClusterAgentProxy: "false" query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" timeout: "10s" ``` **Parameter list:** - `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false) - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) - `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. > 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as "no data" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" # Optional: the HTTP timeout for this trigger timeout: "10s" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ### Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../reference/scaledobject-spec/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ### Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. #### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. #### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ### Cases of unexpected metrics value in DataDog API response #### Latest data point is unavailable By default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue #### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.20/scalers/dynatrace.md ================================================ +++ title = "Dynatrace" availability = "2.15+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Dynatrace metric data points" go_file = "dynatrace_scaler" +++ ### Trigger Specification This specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points. ```yaml triggers: - type: dynatrace metadata: host: https://dummy-instance.live.dynatrace.com/ threshold: "10" # Optional activationThreshold: "5" # Optional metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' # Optional from: now-2d # Optional query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-2d' # Optional queryTimeoutSeconds: "10" # Optional queryPollingWait: "1s" # Optional queryPollingTries: "5" ``` **Parameter list:** - `host` - The Dynatrace instance to query against. (This value can be different when using `metricSelector` than when using `query`) - `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). (Optional, Mutually exclusive with `query`) Some relevant aspects: - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector - `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours, This only applies when `metricSelector` is used; with `query`, the time range must be included within the query) - `query` - [DQL](https://docs.dynatrace.com/docs/discover-dynatrace/platform/grail/dynatrace-query-language) query to be executed. (Optional, Mutually exclusive with `metricSelector`) Some relevant aspects: - Query must return a single scalar named `r` that KEDA will use as metric, other fields will be ignored. - KEDA will poll 5 times the value with a second between tries, so the query needs to have a result within that window. - `queryTimeoutSeconds` - Timeout in seconds passed to fetch data on Dynatrace side (Default: `10`, Optional, Only applies with `query`) - `queryPollingWait` - Time between result polling tries (Default: `1s`, Optional, Only applies with `query`) - `queryPollingTries` - Total polling tries (Default: `5`, Optional, Only applies with `query`) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float) > NOTE: Modifying the values of `queryPollingWait` or `queryPollingTries` can increase the response time and the HPA Controller can register timeouts because of this. If your query requires longer times, you should evaluate options like [caching metrics (`useCachedMetrics`)](./../reference/scaledobject-spec.md#triggers) in addition to these parameters. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure authentication for the `host` and `token` parameters. **Authentication:** - `host` - The Dynatrace instance to query against (This value can be different when using `metricSelector` than when using `query`) - `token` - The API key that will be leveraged to connect to Dynatrace and make requests. For `metricSelector`, token requires the `metrics.read` scope ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). For `query`, token **[has to be a platform token](https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients/platform-tokens)** with enough permissions for the table that you want to use (OIDC client isn't supported). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/ token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: metricSelector: 'MyCustomEvent:filter(eq("someProperty","someValue")):count:splitBy("dt.entity.process_group"):fold' from: 'now-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ### DQL Example ```yaml apiVersion: v1 kind: Secret metadata: name: dynatrace-secret namespace: my-project type: Opaque data: host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5hcHBzLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.apps.dynatrace.com/ token: ZHQwczE2LlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s16.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-dynatrace namespace: my-project spec: secretTargetRef: - parameter: token name: dynatrace-secret key: token - parameter: host name: dynatrace-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: dynatrace-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: dynatrace metadata: query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-30m' threshold: '1000' authenticationRef: name: keda-trigger-auth-dynatrace ``` ### Troubleshooting & Tips #### Required Token Permissions for `query` Parameter When using the `query` parameter (DQL-based queries), your platform token must have **both** of the following scopes: - `storage:metrics:read` - `storage:buckets:read` > **Note:** This is different from `metricSelector`, which only requires `metrics.read`. #### Testing Your Query with Dynatrace Swagger UI You can test your DQL query directly as your token using the Dynatrace Swagger UI before configuring KEDA: ``` https://.apps.dynatrace.com/platform/swagger-ui/index.html?urls.primaryName=Grail+-+DQL+Query#/Query%20Execution/query%3Aexecute ``` Click the **Authorize** button (top right) and enter your platform token to authenticate. This lets you validate your query and permissions before using them in KEDA. #### Example: Scaling Based on GCP Pub/Sub via Dynatrace If your GCP project is onboarded into Dynatrace, you can scale based on Pub/Sub metrics using a DQL query like this: ```yaml triggers: - type: dynatrace metadata: query: >- timeseries value = max(cloud.gcp.pubsub_googleapis_com.subscription.num_unacked_messages_by_region, scalar:true), filter: gcp.project.id == "myproject", from: now()-5m | fields value | append [data record(value = 0.0)] | summarize r = toDouble(max(value)) ``` ================================================ FILE: content/docs/2.20/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html). The trigger always requires the following information, but requires either only searchTemplateName **or** only query: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" query: "my-query" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `query` - The query to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Examples Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" query: | { "size": 0, "query": { "bool": { "must": [ { "term": { "service.name": "my-application" } }, { "term": { "service.environment": "production" } }, { "range": { "@timestamp": { "gte": "now-2m", "lte": "now-1m" } } } ] } }, "aggs": { "transaction_count": { "cardinality": { "field": "transaction.id" } } } } valueLocation: "aggregations.transaction_count.value" targetValue: "1000" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.20/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" category = "Data & Storage" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' usernameFromEnv: # Optional passwordFromEnv: # Optional ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Password based authentication:** - `username` - Username for authentication. (Optional) - `password` - Password for authentication. (Optional) **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on Password auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: etcd-username: etcd-password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-etcd-secrets key: etcd-username - parameter: password name: keda-etcd-secrets key: etcd-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.20/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549 tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 unsafeSsl: false ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.20/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" category = "Extensibility" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 caCert : /path/to/tls/ca.pem tlsClientCert: /path/to/tls/cert.pem tlsClientKey: /path/to/tls/key.pem enableTLS: false unsafeSsl: false ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters - `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional) - `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` Here is an example of external scaler with certificates ```yaml apiVersion: v1 kind: Secret metadata: name: certificate data: ca.crt: "YOUR_CA_IN_SECRET" tls.crt: "YOUR_CERTIFICATE_IN_SECRET" tls.key: "YOUR_KEY_IN_SECRET" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth spec: secretTargetRef: - parameter: caCert name: certificate key: ca.crt - parameter: tlsClientCert name: certificate key: tls.crt - parameter: tlsClientKey name: certificate key: tls.key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: external-scaledobject spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 metricType: mymetric scalerAddress: mydomain.com:443 extraKey: "demo" authenticationRef: name: keda-trigger-auth ``` ================================================ FILE: content/docs/2.20/scalers/forgejo.md ================================================ +++ title = "Forgejo" availability = "v2.18+" maintainer = "Community" category = "CI/CD" description = "Scale applications based on pending jobs on Forgejo repository." go_file = "forgejo_scaler" +++ ### Trigger Specification This specification describes the `forgejo-runner` trigger for Forgejo Actions. It scales based on the amount of jobs pending in given runner labels. ```yaml triggers: - type: forgejo-runner metadata: # Required: the name of the registered runner name: "forgejo-runner-ubuntu" # Required: the url of the forgejo instance address: "http://localhost:3000" # Optional: Scope of the jobs to check, global is the default one and will get all the jobs in the instance with the defined labels global: "true" # Optional: User to set as a scope, global should be false, if no repo is set will get all the pending jobs for the user owner: "cobak" # Optional: Repository level scope repo: "my-repo" # Required: Will get the jobs with match with this labels labels: "ubuntu-latest" ``` **Parameter list:** - `name` - Name of the registered runner. - `address` - Url of the forgejo instance. - `global` - Scope of the jobs to check. (Values: `true`, `false`, Default: `true`, Optional, Mutually exclusive with `owner` and `repo`) - `owner` - User to set as a scope. (Optional, Mutually exclusive with `global` and `repo`) - `repo` - User to set as a scope. (Optional, Mutually exclusive with `global` and `owner`) - `labels` - Labels to match the job with. ### Authentication Parameters - `token` - Required token to connect to forgejo instance. ### Options on how to set the scope (global, user, repo) 1. If you set owner and repo KEDA forgejo scaler will retrieve jobs from that repository: ``` owner: "username" repo: "my_repo" ``` 2. If you set the organization will retrieve the organization jobs: ``` org: "my_org" ``` 3. If you set global: true will retrieve all the jobs from the instance ``` global: "true" ``` 4. And if you don't set any of this optional fields will retrieve the jobs from the user who creates the token ## Configuration ### Registering runners and binding config with autoscalers To match job endpoints with job execution, we need to pre-register a runner, save the generated JSON file as a ConfigMap, and share it with the autoscaler. review the different ways to register a runner [here](https://forgejo.org/docs/latest/admin/runner-installation/#standard-registration), select the desired scope (user, repository or global) and create the corresponding JSON file. Autoscaler definition and runner registration should match to work as expected. Create a .runner file and a registration file with this commands, and set the output in a configmap. ```shell docker run -v /var/run/docker.sock:/var/run/docker.sock -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner register --no-interactive --token xxxx --name runner --instance http://localhost:3000/ --labels ubuntu-20:docker://node:20-bookworm,docker:docker://ghcr.io/catthehacker/ubuntu:act-latest docker run -v /var/run/docker.sock:/var/run/docker.sock -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner generate-config > registration.yaml ``` ```yaml apiVersion: v1 kind: ConfigMap metadata: name: runner-config namespace: runners data: .runner: | { "WARNING": "This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.", "id": 3, "uuid": "be6b5260-e73f-4e21-af84-8e205dbaaacd", "name": "runner", "token": "", "address": "http://localhost:3000/", "labels": [ "ubuntu-20:docker://node:20-bookworm", "docker:docker://ghcr.io/catthehacker/ubuntu:act-latest" ] } --- apiVersion: v1 kind: ConfigMap metadata: name: runner-registration namespace: runners data: registration.yaml: | log: # The level of logging, can be trace, debug, info, warn, error, fatal level: info # The level of logging for jobs, can be trace, debug, info, earn, error, fatal job_level: info runner: # Where to store the registration result. file: /data/.runner # Execute how many tasks concurrently at the same time. capacity: 1 # Extra environment variables to run jobs. envs: DOCKER_HOST: tcp://localhost:2376 DOCKER_TLS_VERIFY: 1 DOCKER_CERT_PATH: /certs/client # Extra environment variables to run jobs from a file. # It will be ignored if it's empty or the file doesn't exist. env_file: .env # The timeout for a job to be finished. # Please note that the Forgejo instance also has a timeout (3h by default) for the job. # So the job could be stopped by the Forgejo instance if it's timeout is shorter than this. timeout: 3h # The timeout for the runner to wait for running jobs to finish when # shutting down because a TERM or INT signal has been received. Any # running jobs that haven't finished after this timeout will be # cancelled. # If unset or zero the jobs will be cancelled immediately. shutdown_timeout: 3h # Whether skip verifying the TLS certificate of the instance. insecure: false # The timeout for fetching the job from the Forgejo instance. fetch_timeout: 5s # The interval for fetching the job from the Forgejo instance. fetch_interval: 2s # The interval for reporting the job status and logs to the Forgejo instance. report_interval: 1s # The labels of a runner are used to determine which jobs the runner can run, and how to run them. # Like: ["macos-arm64:host", "ubuntu-latest:docker://node:20-bookworm", "ubuntu-22.04:docker://node:20-bookworm"] # If it's empty when registering, it will ask for inputting labels. # If it's empty when executing the `daemon`, it will use labels in the `.runner` file. labels: - ubuntu-20:docker://node:20-bookworm - docker:docker://ghcr.io/catthehacker/ubuntu:act-latest cache: # Enable cache server to use actions/cache. enabled: true # The directory to store the cache data. # If it's empty, the cache data will be stored in $HOME/.cache/actcache. dir: "" # The host of the cache server. # It's not for the address to listen, but the address to connect from job containers. # So 0.0.0.0 is a bad choice, leave it empty to detect automatically. host: "" # The port of the cache server. # 0 means to use a random available port. port: 0 # The port of the cache proxy. # 0 means to use a random available port. proxy_port: 0 # The external cache server URL. Valid only when enable is true. # If it's specified, it will be used to set the ACTIONS_CACHE_URL environment variable. The URL should generally end with "/". # Otherwise it will be set to the the URL of the internal cache server. external_server: "" # The shared cache secret. When communicating with a cache server, the runner uses this secret to verify the authenticity of the cache requests. # When using an external cache server it is required to set the same secret for the runner and the cache server. secret: "" # Overrides the ACTIONS_CACHE_URL passed to workflow containers. This should only be used if the runner host is not reachable from the # workflow containers, and requires further setup. actions_cache_url_override: "" container: # Specifies the network to which the container will connect. # Could be host, bridge or the name of a custom network. # If it's empty, create a network automatically. network: host # Whether to create networks with IPv6 enabled. Requires the Docker daemon to be set up accordingly. # Only takes effect if "network" is set to "". enable_ipv6: false # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker). privileged: false # And other options to be used when the container is started (eg, --add-host=my.forgejo.url:host-gateway). options: -v /certs/client:/certs/client # The parent directory of a job's working directory. # If it's empty, /workspace will be used. workdir_parent: # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted. # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to: # valid_volumes: # - data # - /src/*.json # If you want to allow any volume, please use the following configuration: # valid_volumes: # - '**' valid_volumes: - /certs/client # overrides the docker client host with the specified one. # If "-" or "", an available docker host will automatically be found. # If "automount", an available docker host will automatically be found and mounted in the job container (e.g. /var/run/docker.sock). # Otherwise the specified docker host will be used and an error will be returned if it doesn't work. docker_host: "-" # Pull docker image(s) even if already present force_pull: false # Rebuild local docker image(s) even if already present force_rebuild: false host: # The parent directory of a job's working directory. # If it's empty, $HOME/.cache/act/ will be used. workdir_parent: ``` ### Create a token on forgejo The autoscaler will continuously fetch new waiting jobs from Forgejo, so it requires a properly configured token with the appropriate permissions. Navigate to **Forgejo > User settings > Applications > Access Tokens** and generate a new token. This token will be used by the autoscaler ### Configuring KEDA Autoscaler Create a new custom resource with the required parameters and custom fields based on the scope chosen during runner registration. For example, set `global="true"` for global runners or specify `repo=xxx` and `owner=xxx` for repository level runners. Choose the runner image you want to use (>6.1 of forgejo runner releases) or a custom one with `--one-job` command. Apply the new custom resource to your cluster. ```yaml apiVersion: v1 kind: Secret metadata: name: forgejo-runner-secret namespace: runners data: token: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: forgejo-runner-creds namespace: runners spec: secretTargetRef: - parameter: token name: forgejo-runner-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: labels: app: forgejo-runner name: upload-platform-forgejo-runner namespace: runners spec: jobTargetRef: template: metadata: labels: app: forgejo-runner spec: volumes: - name: runner-data emptyDir: {} - name: runner-config configMap: name: upload-platform-runner-config - name: runner-registration configMap: name: upload-platform-runner-registration - name: docker-certs emptyDir: {} restartPolicy: Never shareProcessNamespace: true containers: - name: runner image: code.forgejo.org/forgejo/runner:6.3.1 command: - sh - -c - | while ! nc -z localhost 2376 &1 & while kill -0 7 2>/dev/null do sleep 10 echo "watching main job execution" done; sleep 10 echo "main container exited, stopping dind" exit 0 env: - name: DOCKER_TLS_CERTDIR value: /certs - name: DOCKER_HOST value: tcp://0.0.0.0:2376 securityContext: privileged: true runAsUser: 0 volumeMounts: - name: docker-certs mountPath: /certs minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: forgejo-runner metadata: name: "runner" address: "http://localhost:3000/" global: "true" labels: "ubuntu-20,docker" authenticationRef: name: forgejo-runner-creds ``` ================================================ FILE: content/docs/2.20/scalers/gcp-cloud-tasks.md ================================================ +++ title = "Google Cloud Platform Cloud Tasks" availability = "v2.12+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Cloud Tasks." go_file = "gcp_cloud_tasks_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks. ```yaml triggers: - type: gcp-cloudtasks metadata: value: "5" # Optional - Default is 100 activationValue: "10.5" # Optional - Default is 0 filterDuration: '1' # Optional - Default is 2 queueName: "myqueue" # Required projectID: "myproject" # Required, the project where the queue resides credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue. - `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float) - `queueName` defines the queue that should be monitored. - `projectID` defines the GCP project where the queue that should be monitored resides. - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject namespace: keda-cloudtasks-test spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: cloudtasks-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cloudtasks-scaledobject spec: scaleTargetRef: name: keda-cloudtasks-go triggers: - type: gcp-cloudtasks authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: activationValue: "5" projectID: "myproject" # Required queueName: "myqueue" # Required ``` ================================================ FILE: content/docs/2.20/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pubsub_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # The 'subscriptionSize' setting is DEPRECATED and will be removed in v2.20 - Use 'mode' and 'value' instead" mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge aggregation: "sum" # Optional - Only meaningful for distribution-valued metrics value: "5.5" # Optional - Default is 10 valueIfNull: '0.0' # Optional - Default is "" activationValue: "10.5" # Optional - Default is 0 timeHorizon: "1m" # Optional - Default is 2m and with aggregation 5m # Exactly one of the subscription or topic name options is required subscriptionName: "mysubscription" subscriptionNameFromEnv: "MY_SUBSCRIPTION_FROM_ENV" topicName: "mytopic" topicNameFromEnv: "MY_TOPIC_FROM_ENV" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc. - `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`) - `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`) - `valueIfNull` - Value returned if request returns no timeseries.(Default: `""`, Optional, This value can be a float) - `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. - `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`. - `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas: - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`. - `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using distribution-valued metric and aggregation ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2 mode: "MessageSizes" aggregation: "count" # Calculate count of messages being published value: "50" topicName: "mytopic" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.20/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ > 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md). ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' valueIfNull: '0.0' #Optional - Default is "" filterDuration: '1' # Optional - Default is 2 activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `valueIfNull` - Value return if request return no timeseries.(Default: `""`, Optional, This value can be a float) - `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.20/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.20/scalers/github-runner.md ================================================ +++ title = "Github Runner Scaler" availability = "v2.10+" maintainer = "GitHub" category = "CI/CD" description = "Scale GitHub Runners based on the number of queued jobs in GitHub Actions" go_file = "github_runner_scaler" +++ ### Trigger Specification This specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions. ```yaml triggers: - type: github-runner metadata: # Optional: The URL of the GitHub API, defaults to https://api.github.com githubApiURL: "https://api.github.com" # Required: The owner of the GitHub repository, or the organization that owns the repository owner: "{owner}" # Required: The scope of the runner, can be either "org" (organisation), "ent" (enterprise) or "repo" (repository) runnerScope: "{runnerScope}" # Optional: The list of repositories to scale, separated by comma repos: "{repos}" # Optional: The list of runner labels to scale on, separated by comma labels: "{labels}" # Optional: Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false", defaults to "false" (scale on default runner labels) noDefaultLabels: "{noDefaultLabels}" # Optional: When enabled unlabeled jobs will not match unlabeled runners. Can be either "true" or "false", defaults to "false" matchUnlabeledJobsWithUnlabeledRunners: "{matchUnlabeledJobsWithUnlabeledRunners}" # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either "true" or "false", defaults to "false" enableEtags: "{enableEtags}" # Optional: The target number of queued jobs to scale on targetWorkflowQueueLength: "1" # Default 1 # Optional: The name of the application ID from the GitHub App applicationID: "{applicatonID}" # Optional: The name of the installation ID from the GitHub App once installed into Org or repo. installationID: "{installationID}" authenticationRef: name: personalAccessToken or appKey triggerAuthentication Reference ``` **Parameter list:** - `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScope` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `repos` - The list of repositories to scale, separated by comma. (Optional) - `labels` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabels` - Not scale on default runner labels ("self-hosted", "linux", "x64"). (Values: `true`,`false`, Default: "false", Optional) - `matchUnlabeledJobsWithUnlabeledRunners` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: "false", Optional) - `enableEtags` - Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set) - `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set) *Parameters from Environment Variables* You can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, the scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: "RUNNER_LABELS"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter. - `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional) - `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required) - `runnerScopeFromEnv` - The scope of the runner, can be either "org", "ent" or "repo". (Required) - `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional) - `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional) - `noDefaultLabelsFromEnv` - Not scale on default runner labels ("self-hosted", "linux", "x64"), can be either "true" or "false". (Optional) - `matchUnlabeledJobsWithUnlabeledRunnersFromEnv` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: "false", Optional) - `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1) - `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set) - `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set) ### Authentication Parameters You authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration. **Token or Key Authentication:** - `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used) - `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set) ### Setting up the GitHub App You can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits. 1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app)) 2. Make a note of the Application ID. You will need these to configure the scaler. 3. Disable Webhooks on your GitHub App. 4. Set the permissions for your GitHub App. The following permissions are required: - **Repository permissions** - Actions - Read-only - Administration - Read & Write - Metadata - Read-only - **Organization permissions** - Actions - Read-only - Metadata - Read-only - Self-hosted Runners - Read & write 5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key)) 6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps)) 7. Make a note of the Installation ID. You will need these to configure the scaler. ### How does it work? The scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`, the scaler will scale up. We provide various options to have granular control over what runners to scale: - **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used. - **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`. **API Query Chain** The scaler will query the GitHub API in the following order: - If no repos are specified: Get the list of repos for the specified owner. - For each repo: Get the list of workflows runs in the repo. - For each queued workflow run: Get the list of jobs in the queued workflow run. - For each job: if the scaler matches, increment the queue length for that scaler. **Notes on Rate Limits** GitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting) | Authentication Method | Rate Limit (per hour) | Notes | |---|---|---| | Personal Access Token | 5000 | Standard rate limit | | GitHub App | 15000 | Higher rate limit | | Hosted Appliance | Unlimited | No rate limits apply | Example: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows, and 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds. Careful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations: - Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories. - Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`. The github scaler [handles rate limit errors appropriately](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2026-03-10#handle-rate-limit-errors-appropriately) by waiting until X-RateLimit-Reset or Retry-After times until the github API is queried when rate limited. During this time it will return the cached queue length which is updated with each successful request. **Fine-Tuning** The current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters. For example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly. *Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).* At the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call. **References** GitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) myoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner) ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: github-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: github-runner-scaledobject namespace: default spec: scaleTargetRef: name: gitrunner-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: github-runner metadata: githubApiURL: "https://api.github.com" owner: "kedacore" runnerScope: "repo" repos: "keda,keda-docs" labels: "golang,helm" targetWorkflowQueueLength: "1" authenticationRef: name: github-trigger-auth ``` Alternate example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" authenticationRef: name: github-trigger-auth ``` GitHub App example using ScaledJobs and using myoung34's work on containerised runners: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: github-auth data: appKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: github-trigger-auth namespace: default spec: secretTargetRef: - parameter: appKey name: github-auth key: appKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: scaledjob-github-runner namespace: github-runner spec: jobTargetRef: template: metadata: labels: app: scaledjob-github-runner spec: containers: - name: scaledjob-github-runner image: myoung34/github-runner:2.302.1-ubuntu-focal imagePullPolicy: Always env: - name: EPHEMERAL value: "true" - name: DISABLE_RUNNER_UPDATE value: "true" - name: REPO_URL value: "https://github.com/OWNER/REPONAME" - name: RUNNER_SCOPE value: "repo" - name: LABELS value: "my-label" - name: ACCESS_TOKEN valueFrom: secretKeyRef: name: {{.SecretName}} key: personalAccessToken restartPolicy: Never minReplicaCount: 0 maxReplicaCount: 20 pollingInterval: 30 triggers: - type: github-runner metadata: owner: OWNER repos: REPONAME(S) labelsFromEnv: "LABELS" runnerScopeFromEnv: "RUNNER_SCOPE" applicationID: "1234" installationID: "5678" authenticationRef: name: github-trigger-auth ``` ================================================ FILE: content/docs/2.20/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" category = "Metrics" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.20/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) (**The 'minMetricValue' setting is DEPRECATED and will be removed in v2.20 - Use 'activationTargetMetricValue' instead**) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.20/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret unsafeSsl: "false" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ). - `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example Example with Basic Auth ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages usernameFromEnv: # OPTIONAL - Provide admin username from env instead of as a secret passwordFromEnv: # OPTIONAL - Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` Example with Basic Auth and TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password cert: key: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueName: # REQUIRED - Your queue name queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 20 messages authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD - parameter: cert name: keda-ibmmq-secret key: cert - parameter: key name: keda-ibmmq-secret key: key ``` ================================================ FILE: content/docs/2.20/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org # Required for InfluxDB v2.x, optional for InfluxDB v3.x organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") metricKey: 'mymetric' # Required for Influx v3. Ignored for v2. See details in "Parameter List" section queryType: 'InfluxQL' # Required for Influx v3. Ignored for v2. See details in "Parameter List" section influxVersion: '2' # Optional: Defaults to 2. database: 'some-influx-db' # Required for Influx v3 authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc (Optional, Required if `influxVersion: '2'`). - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `influxVersion` - Specifies the version of InfluxDB being used. (Values: `2`, `3`, Default: `2`, Optional) - `database` - The name of the InfluxDB database to query. Required for InfluxDB v3.x. (Optional for InfluxDB v2.x) - `metricKey` - The name of the metric to be used for scaling decisions. This is required for InfluxDB v3.x and ignored for InfluxDB v2.x. It is used to identify the metric in the query results. For a `query` of `SELECT mean("mymetric") AS "metric_name" FROM...` use `metricKey: 'metric_name'`. (Optional, Required if `influxVersion: '3'`) - `queryType` - Specifies the type of query being used. For InfluxDB v3.x, this can be either `InfluxQL` or `FlightSQL`. For InfluxDB v2.x, this parameter is ignored. (Values: `InfluxQL`, `FlightSQL`, Default: `InfluxQL`, Optional) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example (InfluxDB v2) Below is an example of how to deploy a scaled object with the `InfluxDB` (v2) scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ### Example (InfluxDB v3) Below is a similar example for Influx v3 using an `InfluxQL` query. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 database: 'my-metrics-db' influxVersion: '3' queryType: 'InfluxQL' metricKey: 'mean' thresholdValue: '2' activationThresholdValue: '10' query: | SELECT mean("water_level") FROM "h2o_feet" GROUP BY time(5m) ORDER BY time DESC LIMIT 1; authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.20/scalers/kubernetes-resource.md ================================================ +++ title = "Kubernetes Resource" availability = "v2.19+" maintainer = "Community" category = "Kubernetes" description = "Scale applications based on values in Kubernetes ConfigMaps or Secrets" go_file = "kubernetes_resource_scaler" +++ ### Trigger Specification This specification describes the `kubernetes-resource` trigger that scales based on a value found in a Kubernetes ConfigMap or Secret. This scaler allows users to scale workloads by extracting values from Kubernetes resources, supporting number, JSON, and YAML formats. Here is an example of trigger configuration using kubernetes-resource scaler: ```yaml triggers: - type: kubernetes-resource metadata: resourceKind: "Secret" resourceName: "my-secret" key: "data" format: "json" valueLocation: "count" valueType: "float64" targetValue: "10" activationTargetValue: "5" ``` **Parameter list:** - `resourceKind` - Type of Kubernetes resource to read from. Supported values: `ConfigMap`, `Secret` (Required) - `resourceName` - Name of the resource to read. (Required) - `key` - Key in the ConfigMap's `data` field or Secret's `data` field to read from. The value at this key is retrieved as a string. (Required) - `format` - Format of the string value retrieved from `key`. Supported values: `number`, `json`, `yaml`. (Default: `number`, Optional) - `number` - The string value is parsed directly as a number - `json` - The string value is a JSON document, and `valueLocation` extracts a field from it - `yaml` - The string value is a YAML document, and `valueLocation` extracts a field from it - `valueLocation` - Path to extract the metric value from the JSON or YAML content retrieved from `key`. Required for `json` and `yaml` formats. Not used for `number` format. For `json`, use [GJSON path notation](https://github.com/tidwall/gjson#path-syntax). For `yaml`, use dot-separated path (e.g., `foo.bar.count`). (Optional) - `valueType` - Type of value to extract. Supported values: `float64`, `int64`, `quantity`. (Default: `float64`, Optional) - `float64` - Floating point number. For JSON format, accepts both numbers and quantity strings. - `int64` - Integer number. For JSON format, only accepts integer numbers (decimal values are truncated). For `number` format, the string must be parseable as an integer. - `quantity` - Kubernetes quantity (e.g., "100m", "1Gi"). For JSON/YAML formats, parses string values as quantities. For JSON format, also accepts raw numbers. - `targetValue` - Target value to scale on. When the extracted value is equal or higher, KEDA will scale out. (Required) - `activationTargetValue` - Value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters No authentication parameters are required. The scaler uses the permissions of the KEDA operator to access resources in the same namespace. ### Example Here is a full example of scaled object definition using Kubernetes Resource trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: k8s-resource-scaledobject namespace: keda spec: maxReplicaCount: 10 scaleTargetRef: name: dummy triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "my-configmap" key: "metrics" format: "yaml" valueLocation: "count" valueType: "int64" targetValue: "10" ``` Assuming the ConfigMap contains: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: my-configmap namespace: keda data: metrics: | count: 12 other: value ``` The scaler will extract the value at `count` from the YAML data in the `metrics` key and use it for scaling decisions. > 💡 **NOTE:** > - The `valueType` parameter controls how values are parsed. For `int64`, decimal values in JSON are truncated to integers. > - For `json` format, use GJSON path syntax. For `yaml` format, use dot-separated path. For `number` format, the value at the key is used directly. > - For YAML format, the `valueType` determines how the extracted value is converted, regardless of whether the value is a string or a native YAML number. For example, if `valueType` is set to `int64`, the value will be converted to an integer; if set to `quantity`, it will be parsed as a Kubernetes quantity. By default, numeric YAML values are converted to float64 unless a different `valueType` is specified. ### Additional Examples #### Example 1: Number Format (Direct Value) ```yaml apiVersion: v1 kind: ConfigMap metadata: name: task-count namespace: keda data: count: "42" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: task-scaler namespace: keda spec: scaleTargetRef: name: worker-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "task-count" key: "count" format: "number" valueType: "float64" targetValue: "50" activationTargetValue: "10" ``` In this example, the value `42` from the `count` key is used directly. #### Example 2: JSON Format ```yaml apiVersion: v1 kind: Secret metadata: name: metrics-data namespace: keda stringData: metrics: | { "queue": { "pending": 25, "processing": 5 } } --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: queue-scaler namespace: keda spec: scaleTargetRef: name: processor-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "Secret" resourceName: "metrics-data" key: "metrics" format: "json" valueLocation: "queue.pending" valueType: "int64" targetValue: "20" ``` In this example, the GJSON path `queue.pending` extracts the value `25` from the JSON data. #### Example 3: YAML Format with Nested Path ```yaml apiVersion: v1 kind: ConfigMap metadata: name: app-metrics namespace: keda data: stats: | application: workers: active: 15 idle: 3 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: worker-scaler namespace: keda spec: scaleTargetRef: name: worker-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "app-metrics" key: "stats" format: "yaml" valueLocation: "application.workers.active" valueType: "int64" targetValue: "10" ``` In this example, the dot-separated path `application.workers.active` extracts the value `15` from the YAML data. #### Example 4: Quantity Type ```yaml apiVersion: v1 kind: ConfigMap metadata: name: resource-limits namespace: keda data: memory: | { "available": "2Gi", "used": "512Mi" } --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaler namespace: keda spec: scaleTargetRef: name: worker-deployment triggers: - type: kubernetes-resource metadata: resourceKind: "ConfigMap" resourceName: "resource-limits" key: "memory" format: "json" valueLocation: "used" valueType: "quantity" targetValue: "1024000000" # 1Gi in bytes ``` In this example, the quantity string `"512Mi"` is parsed and converted to its float64 representation for scaling decisions. > ⚠️ **Important:** When using `valueType: "int64"` with JSON format, decimal values will be truncated. For example, if the JSON contains `{"count": 25.7}`, it will be treated as `25`. ### Supported Formats and Value Extraction The scaler works in two steps: 1. **Retrieve the raw string**: Read the value from `ConfigMap.data[key]` or `Secret.data[key]` 2. **Extract the metric**: Parse the raw string based on the `format`: - **number**: The raw string is parsed directly as a number. No `valueLocation` is needed. - Example: If `key="count"` and `ConfigMap.data.count = "42"`, the metric value is `42` - **json**: The raw string is parsed as JSON, then `valueLocation` (using GJSON syntax) extracts the metric value. - Example: If `key="metrics"` and `ConfigMap.data.metrics = '{"tasks": 10}'`, with `valueLocation="tasks"`, the metric value is `10` - **yaml**: The raw string is parsed as YAML, then `valueLocation` (using dot-separated path) extracts the metric value. - Example: If `key="stats"` and `ConfigMap.data.stats = 'count: 15'`, with `valueLocation="count"`, the metric value is `15` ### Limitations - Only resources in the same namespace as the ScaledObject are supported. - No cross-namespace access. - Only ConfigMaps and Secrets are supported. - The scaler uses the KEDA operator's service account permissions to access resources. ### See Also - [KEDA Concepts: Activating and Scaling Thresholds](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) - [GJSON Path Syntax](https://github.com/tidwall/gjson#path-syntax) ================================================ FILE: content/docs/2.20/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" category = "Apps" description = "Scale applications based on the count of matching non-terminated pods, optionally grouped by node." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' groupByNode: 'true' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) used to match pods for this scaler. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the count computed by this scaler. By default, the count is the number of matching non-terminated pods. If `groupByNode` is set to `true`, the count is the number of unique nodes hosting matching non-terminated pods. Matching pods without a node assignment are excluded. It will be calculated following this formula: `relation = (scaler-computed count) / (scaled workload pods)`. (This value can be a float) - `groupByNode` - When set to `true`, matching non-terminated pods are grouped by `spec.nodeName`, so multiple matching pods on the same node count as `1`. Matching pods without an assigned node are excluded. (Default: `false`, Optional) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. When `groupByNode` is enabled, KEDA groups matching non-terminated pods by node and excludes matching pods without a node assignment. For example, if `7` matching pods are found and `2` of them run on the same node, the scaler reports `6`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' groupByNode: 'true' ``` ================================================ FILE: content/docs/2.20/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.20/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.20/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" category = "Apps" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`. - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.20/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" format: "json" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" timeout: "1000" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). If `aggregateFromKubeServiceEndpoints` is set to `true`, the URL must use Kubernetes DNS format: `http://.[.svc.cluster.local]:/path`, where the port must be the pod port targeted by the service, not the service port. - `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional) - `valueLocation` - The location of the metric value in the response payload. The value is format specific. * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing. * `{foo: {bar: 42}}` - `foo.bar` will return 42 * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42 * same syntax is used for `yaml`, `xml` and `prometheus` formats. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - Timeout for this specific trigger. Can be given as a number (in milliseconds) or in a human-readable format like "30s". This value will override the value defined in KEDA_HTTP_DEFAULT_TIMEOUT. (Optional) - `aggregateFromKubeServiceEndpoints` - Whether to treat `url` as a kubernetes service and scrape/aggregate metrics for all of this service's endpoints. (Values: `true`, `false`, Default: `false`, Optional) - `aggregationType` - How to aggregate metrics when `aggregateFromKubeServiceEndpoints` is set to `true`, ignored otherwise. (Values: `average`, `sum`, `max`, `min`, Default: `average`, Optional) ### Note on aggregation from kubernetes service when setting `aggregateFromKubeServiceEndpoints: true` in metadata, Metrics API Scaler is able to compute basic `average`, `sum`, `min` or `max` aggregation asked by `aggregationType` metadata from all endpoint targets of a kubernetes API service, which is a handy feature in an environment where one didn't set up a metric aggregator/scraping stack (i.e prometheus), or simply doesn't want to use their monitoring stack to fetch and serve metrics from customers workload in their own kubernetes clusters, and leave the metrics API's responsibility up to the customer This specific behavior comes from the fact that querying a kubernetes service directly (= setting `aggregateFromKubeServiceEndpoints: false`) would return the metric from a single replica randomly, depending on the load-balancing configuration for the service, and lead to inconsistent HPA average metric computation and eventually to scaling issues as metrics from all replicas won't be taken into account Here is an example of a ScaledObject using `aggregateFromKubeServiceEndpoints`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "8.8" url: "http://my-service.my-namespace.svc.cluster.local:8080/api/v1/stats" valueLocation: "components.worker.tasks" aggregateFromKubeServiceEndpoints: "true" aggregationType: "sum" ``` ### Authentication Parameters Metrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS authentication, and Bearer authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below. Multiple authentication methods can be used simultaneously by providing a comma-separated list in the `authMode` parameter, for example `authMode: "apiKey,tls"` enables both API key and TLS certificate authentication in a single request. **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.20/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # scheme of the MongoDB server. if using MongoDB Altas, you can set it to "mongodb+srv" scheme: "mongodb" # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" ``` **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. This value can be a float. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb[+srv]://:@mongodb-svc..svc.cluster.local:27017/ ``` ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional) - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.20/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" category = "Data & Storage" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. **Azure AD Workload Identity authentication:** > Available in v2.20+ #### Prerequisites: - The Azure SQL server has an Azure AD admin configured. See [Microsoft Learn: Configure and manage Microsoft Entra authentication with Azure SQL](https://learn.microsoft.com/azure/azure-sql/database/authentication-aad-configure). - The user-assigned managed identity (UAMI) is federated to the Kubernetes service account used to authenticate against Azure SQL. See the [Considerations about Federations and Overrides](./../authentication-providers/azure-ad-workload-identity.md#considerations-about-federations-and-overrides) section, and the [azure-workload-identity federated credential docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) for the underlying setup. - A contained database user mapped to the UAMI exists in the target database, e.g. `CREATE USER [] FROM EXTERNAL PROVIDER;`, and has been granted access to the objects referenced in the scaler's query. See [Microsoft Learn: Azure AD authentication overview](https://learn.microsoft.com/azure/azure-sql/database/authentication-aad-overview). When `azure-workload` pod identity is used, KEDA acquires an Azure AD access token and uses it as the credential for each query — no `password` / `passwordFromEnv` is required. The scaler accepts the same individual connection parameters as **Password authentication**, with `username` set to the UAMI's contained-database user name: - `host` - FQDN of the Azure SQL server (e.g. `.database.windows.net`). - `port` - The port number of the MSSQL endpoint. (Default: `1433`, Optional) - `database` - The name of the database to query. - `username` - Name of the UAMI's contained database user. #### Remarks KEDA refreshes the Azure AD access token automatically before its expiry. Tokens are scoped to the Azure SQL resource (`https://database.windows.net/.default`). #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-mssql-wi-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql authenticationRef: name: azure-mssql-wi-auth metadata: host: port: "1433" database: username: query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 ``` ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.20/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. - `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.20/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Some parameters of the JetStream details can be pulled from `TriggerAuthentication` objects: - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.20/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ > **Notice:** > The Stan scaler (NATS Streaming) is DEPRECATED and will be removed in v2.19 - Use scaler [nats-jetstream](./nats-jetstream.md) instead. > See also the deprecation notice [here](https://nats-io.gitbook.io/legacy-nats-docs/nats-streaming-server-aka-stan). ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. **TLS Authentication** - `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### Example without any TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with no TLS ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` #### Example with TLS ```yaml apiVersion: v1 kind: Secret metadata: name: keda-stan-secrets namespace: default data: tls: enable ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: default spec: secretTargetRef: - parameter: tls name: keda-stan-secrets key: tls - parameter: ca name: keda-stan-secrets key: ca - parameter: cert name: keda-stan-secrets key: cert - parameter: key name: keda-stan-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "true" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.20/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" category = "Metrics" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example Autoscaling trigger based on transaction duration average metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` Autoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric: ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO" noDataError: "true" threshold: '300' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.20/scalers/nsq.md ================================================ +++ title = "NSQ" availability = "v2.17+" maintainer = "Community" category = "Messaging" description = "Scale applications based on NSQ topic/channel depth." go_file = "nsq_scaler" +++ ### Trigger Specification This specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. ```yaml triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" useHttps: "false" unsafeSsl: "false" ``` **Parameter list:** - `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `:`. - `topic` - Name of the NSQ datastream that the `channel` relates to. - `channel` - Name of the channel used to calculate depth. - `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional) - `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional) - `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) > **Notice:** > - Since ["channels are created on first use by subscribing to the named channel"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0. > - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nsq-scaledobject spec: scaleTargetRef: name: nsq-consumer-deployment triggers: - type: nsq metadata: nsqLookupdHTTPAddresses: "nsq-nsqlookupd.nsq:4161" topic: "example_topic" channel: "example_channel" depthThreshold: "10" activationDepthThreshold: "0" ``` ================================================ FILE: content/docs/2.20/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" category = "Metrics" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.20/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" category = "Metrics" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.20/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for three connection options: A user can offer a full connection string (often in the form of an environment variable secret). - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. It is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity. More details and an example are provided down below. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return a numeric value (integers and floats are both supported). - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" ``` ### Authentication Parameters You can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` **Azure Access Token authentication:** #### Prerequisites: - The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity). - The UAMI should be granted access to the table mentioned in the query performed by KEDA. This can be achieved by: - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role. - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like `GRANT ALL ON TO "";`. Next, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process. - `host` - FQDN of the Azure Postgres Flexible Server. - `userName` - Name of the UAMI Azure identity (``). - `port` - Postgresql port (the default value is `"5432"`, please have a look at the `Remarks` down below). - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database (the value should be `require`). #### Remarks - While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port. #### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-pg-flex-auth spec: podIdentity: provider: azure-workload # Optional-> identityId: # Optional-> identityTenantId: --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql authenticationRef: name: azure-pg-flex-auth metadata: host: port: "5432" userName: dbName: sslmode: require query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.20/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" category = "Metrics" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.20/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost queryParameters: key-1=value-1,key-2=value-2 unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint timeout: "1000" # Optional. Custom timeout for the HTTP client used in this scaler ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) - `timeout` - Timeout **for this specific trigger**. Can be given as a number (in milliseconds) or in a human-readable format like "30s". This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional) ### Authentication Parameters Prometheus Scaler supports various types of authentication to help you integrate with Prometheus. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. **Custom authentication:** - `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration. - `customAuthHeader`: Custom Authorization Header name to be used. This is required field. - `customAuthValue`: Custom Authorization Header value. This is required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Integrating Cloud offerings #### Amazon Managed Service for Prometheus Amazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service. - [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods. - Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account - Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries. - Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity. Using the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage. To gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp). #### Azure Monitor Managed Service for Prometheus Azure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that. - [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example. - `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`. - No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth. - Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics. To gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus). #### Google Managed Service for Prometheus Google Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics. By utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism. See the following steps to configure the scaler integration. - Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator; - Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM). - No other auth (via `authModes`) should be provided other than GCP workload identity auth; - Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus): - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID. To gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus). ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` #### Example: Bearer Authentication Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` #### Example: Basic Authentication Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` #### Example: TLS Authentication Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` #### Example: TLS & Basic Authentication Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` #### Example: Custom Authentication Here is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: customAuthHeader: "X-AUTH-TOKEN" customAuthValue: "auth-token" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: customAuthHeader name: keda-prom-secret key: customAuthHeader - parameter: customAuthValue name: keda-prom-secret key: customAuthValue --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "custom" authenticationRef: name: keda-prom-creds ``` #### Example: Azure Monitor Managed Service for Prometheus Here is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-managed-prometheus-trigger-auth spec: podIdentity: provider: azure-workload identityId: # Optional. Default: Identity linked with the label set when installing KEDA. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' authenticationRef: name: azure-managed-prometheus-trigger-auth ``` #### Example: Amazon Managed Service for Prometheus (AMP) Below is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials spec: podIdentity: provider: aws --- apiVersion: apps/v1 kind: Deployment metadata: name: keda-deploy labels: app: keda-deploy spec: replicas: 0 selector: matchLabels: app: keda-deploy template: metadata: labels: app: keda-deploy spec: containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 80 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-so labels: app: keda-deploy spec: scaleTargetRef: name: keda-deploy maxReplicaCount: 2 minReplicaCount: 0 cooldownPeriod: 1 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 15 triggers: - type: prometheus authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: {{.AwsRegion}} serverAddress: "https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}" query: "vector(100)" threshold: "50.0" identityOwner: operator ``` #### Example: Google Managed Prometheus Below is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: google-workload-identity-auth spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: google-managed-prometheus-scaler spec: scaleTargetRef: name: deployment-name-to-be-scaled minReplicaCount: 1 maxReplicaCount: 20 triggers: - type: prometheus metadata: serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) threshold: '50.0' authenticationRef: kind: ClusterTriggerAuthentication name: google-workload-identity-auth ``` ================================================ FILE: content/docs/2.20/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" category = "Messaging" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) - `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. **OAuth 2** When configuring OAuth Authentication, configure the following: - `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional) - `scope` - A comma separated lists of OAuth scopes. (Optional) - `clientID`: Client ID for the OAuth provider. (Optional) - `clientSecret`: Client secret for the OAuth provider. (Optional) - `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional) These can also be configured in the trigger metadata except the `clientSecret` ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### OAuth Authentication In order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: oauthTokenURI: scope: clientID: clientSecret: endpointParams: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: oauthTokenURI name: keda-pulsar-secrets key: oauthTokenURI - parameter: scope name: keda-pulsar-secrets key: scope - parameter: clientID name: keda-pulsar-secrets key: clientID - parameter: clientSecret name: keda-pulsar-secrets key: clientSecret - parameter: endpointParams name: keda-pulsar-secrets key: endpointParams --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` You can also use the following example without `authenticationRef` if your OAuth provider supports. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "oauth" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' oauthTokenURI: http://oauth.com/oauth2/token scope: clientID: endpointParams: ``` ================================================ FILE: content/docs/2.20/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" category = "Messaging" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://:/ # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either `amqp`, `http`, or `auto` for auto-detection based on the `host` value. Default value is `auto`. mode: QueueLength # Supported modes are `QueueLength`, `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` or `ExpectedQueueConsumptionTime` value: "100.50" # A value defining the threshold (per instance) that, when exceeded, triggers the scaling. activationValue: "10.5" # Optional. Activation threshold, which by default is 0. queueName: testqueue # Name of the queue. vhostName: / # Optional. If not specified, use the VHost in the `host` connection string. Required for Azure AD Workload Identity authorization (see below). # You can use existing environment variables to read configuration from. For details see "Parameters list" section. hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter. usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of `TriggerAuthentication`. passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of `TriggerAuthentication`. unsafeSsl: true # Optional. Whether to allow unsafe SSL connections. timeout: 1000 # Optional. Custom timeout for the HTTP client used in this scaler. ``` **Parameters list:** - `host` - RabbitMQ host address in the format `://:/vhost`. If the protocol is HTTP than the host may follow this format `http://://`. In example, the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain `vhost`, then the trailing slash is required, e.g. `http://guest:password@localhost:5672/`. When using a username with password consider using `hostFromEnv` or a `TriggerAuthentication`. - `queueName` - Name of the queue to read required information and stats from. - `mode` - Trigger mode. See [Choosing the right trigger mode](#choosing-the-right-trigger-mode) for additional details. Can be one of: - `QueueLength` - trigger on number of messages in the queue - `MessageRate` - trigger on the publishing rate reported by the queue - `DeliverGetRate` - trigger on the rate of delivered messages (to consumers or in response to `basic.get`, both acknowledged and not) reported by the queue - `PublishedToDeliveredRatio` - trigger on the value of ratio of `MessageRate` to `DeliverGetRate` - `ExpectedQueueConsumptionTime` - trigger on the value of expected time (in seconds) of consumption of all messages currently available in the queue (utilizes `QueueLength`, `MessageRate` and `DeliverGetRate` metrics). - `value` - A value defining the threshold (per instance) that, when exceeded, triggers the scaling (can be a floating-point number depending on the trigger mode). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) (default: `0`; optional; can be a floating-point number). - `protocol` - Protocol to be used for communication (values: `auto`, `http`, `amqp`; default: `auto`; optional). - `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (it's optional by default but **it is required** if Azure AD Workload Identity authorization is used). - `queueLength` - **DEPRECATED: please use `mode: QueueLength` and `value: ##` instead**. Defines a threshold value for the queue length passed to the scaler. For example: if one pod can handle 10 messages, set the queue length target to `10`. If the actual number of messages in the queue is 30, the scaler will scale up to 3 pods. Default is set to `20` unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of using full name (values: `true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol). - `pageSize` - This parameter allows setting the page size (default: `100`; optional; only applies when `useRegex` is set to `true`). - `operation` - Operation that will be applied to compute the number of messages in case when `useRegex` is enabled (values: `sum`, `max`, `avg`; defaults: `sum`; optional). - `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT` (optional; only applies to hosts that use the `http` protocol). - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (ready messages only; values:`true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol). - `unsafeSsl` - Whether to allow unsafe SSL connections (values: `true`, `false`, default: `false`). Some parameters can be provided using environment variables instead of setting them directly in metadata: - `hostFromEnv` - reads the host and port of the RabbitMQ server from selected environment variable (in similar format as `host` parameter) - `usernameFromEnv` - reads the username from selected environment variable, which is used to connect to the broker’s management endpoint - `passwordFromEnv` - reads the password from selected environment variable, which is used to connect to the broker’s management endpoint. > 💡 **Notes:** > - `host`/`hostFromEnv` has an optional VHost name after the host slash which will be used to scope API request > - when using `host`/`hostFromEnv` or `TriggerAuthentication`, the supplied password cannot contain special characters > - trigger modes `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` require `http` protocol. > - setting `useRegex` to `true` also requires `protocol` to be set to `http`. > ⚠ **Important:** > - If you have unacknowledged messages and you want to have these counted for the scaling to happen, make sure to utilize the `http` protocol (only REST API interface allows for these to be counted). > - If scaling against many is desired, then the `ScaledObject` should have all desired triggers defined. HPA will scale based on the largest result considering each of triggers independently. ### Choosing the right trigger mode Below you can find available trigger modes with most common usage scenarios: - `QueueLength` - Mainly used to scale messages consuming services, where it is desired to keep number of messages in the queue at selected, nominal level. - `MessageRate` - Mainly used to scale messages consuming services, where it is desired to keep the consumption rate up to messages publication rate (or higher). - `DeliverGetRate` - This specific trigger is actually a byproduct of the resulting implementation of `PublishedToDeliveredRatio` trigger (it was implemented to be used within `scalingModifiers` as a part of composite metric), yet it still has its use in some scenarios. E.g. assuming there's a well known consumer service performance ballpark, `DeliverGetRate` trigger can be utilized to scale out messages publishing service in order to increase publication rate. In this particular example however, upper publication rate limit must be properly guarded by another trigger or by [`maxReplicaCount`](./../reference/scaledobject-spec/#maxreplicacount) so as not to scale infinitely (which could result in overloading the broker, or consumers, or both). - `PublishedToDeliveredRatio` - This trigger is used mainly to control consumer pods scaling to keep publishing and consuming rates at stable level. Assuming that this is the case, the principle of operation is this: - if publishing rate is greater than `value` (usually it is a value slightly above `1`), trigger will initiate scale-out process to launch more consumer pods - if publishing rate is equal to consumption rate (value `1`) then it is the indicator that capacity of consumers is sufficient for handling ongoing messages processing and no additional pods need to be added to the pool - if ratio is below `1`, HPA can gracefully take down some consumers but keep messages processing rate at stable level. - `ExpectedQueueConsumptionTime` - A trigger primarily used to scale consumer pods, which uses estimate value of pending time to deliver all available messages in the queue to the consumers. If it becomes active in this particular scenario, returned metric indicates growing number of messages due either increased publishing rate or degraded performance of currently active number of consumers. It relies on proper setting of `pollingInterval` (see below for details). > ⚠ **Important:** > - With `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` it is advised to set `metricType: Value` in the trigger configuration to rely on absolute metric value and not the average value across all scaled pods. For reference see [`triggers.metricType`](./../reference/scaledobject-spec/#triggers) and [`scalingModifiers.metricType`](./../reference/scaledobject-spec/#scalingmodifiersmetrictype). > - When using `PublishedToDeliveredRatio`, having stable publication to consumption rate may not indicate that consumers pool is of the right size to do the job, since the messages consuming capabilities can change over time, which may result in much higher number of consumers than actually needed. It is then recommended to periodically re-evaluate consumers pool size using different, probably external metric (e.g. consumers count number, size of prefetch buffer, consumer performance, etc.). > - Since `ExpectedQueueConsumptionTime` trigger mode is based on the expected time (in seconds) for the selected queue to be emptied of all messages (including estimated count of published messages during sample probing), it must be served with `pollingInterval` set to 1 second. However, in case where such frequent polling may be expensive, it is recommended to use `ExpectedQueueConsumptionTime` in `scalingModifiers` using additional triggers values in formula like so: `(ExpectedQueueConsumptionTime - (QueueLength / DeliverGetRate)) * pollingInterval + (QueueLength / DeliverGetRate)`. ### Authentication Parameters `TriggerAuthentication` CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. - `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (optional, but **required** if Azure AD Workload Identity authorization is used). #### Username and Password based authentication This allows sensitive credentials to be stored and managed separately from the connection string: - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. > 💡 **Note:** If username or password are set in `TriggerAuthentication` or environment variables, they will override any credentials provided in the `host` parameter. #### TLS authentication - `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ will not be used. Valid values are `enable` or `disable` (optional; the default is `disable`). - `ca` - Certificate authority file for TLS client authentication (optional). - `cert` - Certificate for client authentication (optional). - `key` - Certificate Key for client authentication (optional). > 💡 **Note:** Using RabbitMQ host with AMQPS protocol will require enabling the TLS settings and passing the required parameters. #### Azure Workload Identity authentication For RabbitMQ with OIDC support (>= 3.11) you can use `TriggerAuthentication` CRD with `podIdentity.provider = azure-workload` and with `workloadIdentityResource` parameter, which will hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Currently, only HTTP protocol is supported for AKS Workload Identity. ### Configuration examples #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672 vhostName: vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: vhostName name: keda-rabbitmq-secret key: vhostName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQP protocol with username and password authorization: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://localhost:5672/vhost (no username/password) username: # base64 encoded value of username password: # base64 encoded value of password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: username name: keda-rabbitmq-secret key: username - parameter: password name: keda-rabbitmq-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### AMQPS protocol with TLS authorization: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqps://guest:password@localhost:5672/vhost tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: tls name: keda-rabbitmq-secret key: tls - parameter: ca name: keda-rabbitmq-secret key: ca - parameter: cert name: keda-rabbitmq-secret key: cert - parameter: key name: keda-rabbitmq-secret key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `MessageRate` and `QueueLength` triggers): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger) and enabled `useRegex`: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `QueueLength` trigger) with Azure Workload Identity: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://localhost:15672/ !! no password !! clientId: # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id) --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: podIdentity: provider: azure-workload secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host - parameter: workloadIdentityResource name: keda-rabbitmq-secret key: clientId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http vHostName: / queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (with `DeliverGetRate` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value metadata: protocol: http queueName: testqueue mode: DeliverGetRate value: "30" authenticationRef: name: rabbitmq-trigger-auth ``` #### HTTP protocol (with `PublishedToDeliveredRatio` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value metadata: protocol: http queueName: testqueue mode: PublishedToDeliveredRatio value: "1.1" authenticationRef: name: rabbitmq-trigger-auth ``` #### HTTP protocol (with `PublishedToDeliveredRatio` trigger used together with `scalingModifiers`) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metricType: Value name: p2d_ratio metadata: protocol: http queueName: testqueue mode: PublishedToDeliveredRatio value: "1" authenticationRef: name: rabbitmq-trigger-auth - type: rabbitmq name: qlen metadata: protocol: http queueName: testqueue mode: QueueLength value: "100" authenticationRef: name: rabbitmq-trigger-auth advanced: # Bind QueueLength and PublishedToDeliveredRatio together to control trigger value scalingModifiers: metricType: Value # Trigger if either one of conditions is met: # - publishing to delivery rate exceeds factor of 1.2 # - queue length contains more than 1.2K messages formula: "max(p2d_ratio, qlen/1000)" target: 1.2 ``` #### HTTP protocol (with `ExpectedQueueConsumptionTime` trigger) ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/path/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment pollingInterval: 1 triggers: - type: rabbitmq metricType: Value name: eqct metadata: protocol: http queueName: testqueue mode: ExpectedQueueConsumptionTime value: "20" authenticationRef: name: rabbitmq-trigger-auth ``` ================================================ FILE: content/docs/2.20/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.20/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.20/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.20/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.20/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" category = "Data & Storage" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "myprimary" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" sentinelMaster: "myprimary" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.20/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. There are three ways to configure `redis-streams` trigger: 1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream 2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen)) 3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream streamLength: "50" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger lagCount: "5" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger activationLagCount: "3" # required if lagCount is provided - lag count at which scaler triggers enableTLS: "false" # optional unsafeSsl: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. > Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength` - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional) - `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional) - `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` **TLS:** Parameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check. - `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret - parameter: tls name: redis-streams-auth key: tls - parameter: ca name: redis-streams-auth key: ca - parameter: cert name: redis-streams-auth key: cert - parameter: key name: redis-streams-auth key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` #### Using `streamLength` To scale based on redis stream `XLEN` don't set `consumerGroup`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 20 cooldownPeriod: 200 maxReplicaCount: 10 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream streamLength: "50" ``` #### Using `lagCount` To scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 lagCount: "10" activationLagCount: "3" ``` ================================================ FILE: content/docs/2.20/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars, SeleniumHQ" category = "Testing" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration with default values represent. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: '' # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`). browserVersion: '' # Optional. platformName: '' # Optional. unsafeSsl: false # Optional. activationThreshold: 0 # Optional. nodeMaxSessions: 1 # Optional. enableManagedDownloads: true # Optional. capabilities: '' # Optional. ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional). - `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional). - `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional) **Trigger Authentication** - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional) - `accessToken` - Access token. This is required when `authType` is set a value. (Optional) ### Example --- #### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion` Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' ``` Noted: - From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details. The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` With above script, the request is sent to Grid. Via GraphQL response, it looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 0, "totalSlots": 0 }, "nodesInfo": { "nodes": [] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` In Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata. When the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like ```json { "data": { "grid": { "sessionCount": 0, "maxSession": 1, "totalSlots": 1 }, "nodesInfo": { "nodes": [ { "id": "UUID-of-Node", "status": "UP", "sessionCount": 0, "maxSession": 1, "slotCount": 1, "stereotypes": "[{\"slots\": 1, \"stereotype\": {\"browserName\": \"chrome\", \"browserVersion\": \"\", \"platformName\": \"Linux\"}}]", "sessions": [] } ] }, "sessionsInfo": { "sessionQueueRequests": [ "{\"browserName\": \"chrome\", \"platformName\": \"linux\"}" ] } } } ``` Now, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in. --- #### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName` Moreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome-131 labels: deploymentName: selenium-node-chrome-131 spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:131.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '131.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-131 namespace: keda labels: deploymentName: selenium-node-chrome-131 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-131 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '131.0' unsafeSsl: 'true' ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '131.0') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` #### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads` In image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS value: "true" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Scaler trigger param configuration should be aligned with Node stereotype. enableManagedDownloads: "true" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid options.enable_downloads = True driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata with extra `capabilities` For an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:132.0 ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '132.0' - name: SE_NODE_PLATFORM_NAME value: 'Linux' # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options - name: SE_NODE_STEREOTYPE_EXTRA value: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-chrome-132 namespace: keda labels: deploymentName: selenium-node-chrome-132 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome-132 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' browserVersion: '132.0' unsafeSsl: 'true' # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536 capabilities: "{\"myApp:version\":\"beta\", \"myApp:publish:\":\"public\"}" ``` The request to trigger this scaler should be ```python options = ChromeOptions() options.set_capability('platformName', 'Linux') options.set_capability('browserVersion', '132.0') # Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes options.set_capability('myApp:version', 'beta') options.set_capability('myApp:publish', 'public') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Firefox browser ```yaml kind: Deployment metadata: name: selenium-node-firefox labels: deploymentName: selenium-node-firefox spec: replicas: 1 template: spec: containers: - name: selenium-node-firefox image: selenium/node-firefox:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-firefox namespace: keda labels: deploymentName: selenium-node-firefox spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-firefox triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = FirefoxOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Edge browser Similarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml kind: Deployment metadata: name: selenium-node-edge labels: deploymentName: selenium-node-edge spec: replicas: 1 template: spec: containers: - name: selenium-node-edge image: selenium/node-edge:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-scaledobject-edge namespace: keda labels: deploymentName: selenium-node-edge spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-edge triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' platformName: 'Linux' unsafeSsl: 'true' ``` Request to trigger the scaler ```python options = EdgeOptions() options.set_capability('platformName', 'Linux') driver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL) ``` --- #### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions` In case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior. ```yaml kind: Deployment metadata: name: selenium-node-chrome labels: deploymentName: selenium-node-chrome spec: replicas: 1 template: spec: containers: - name: selenium-node-chrome image: selenium/node-chrome:latest ports: - containerPort: 5555 env: - name: SE_NODE_BROWSER_VERSION value: '' - name: SE_NODE_PLATFORM_NAME value: 'Linux' - name: SE_NODE_OVERRIDE_MAX_SESSIONS value: 'true' - name: SE_NODE_MAX_SESSIONS value: '4' --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' platformName: 'Linux' nodeMaxSessions: 4 unsafeSsl: 'true' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. - `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) - `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional) ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL graphql-username: base64 encoded value of GraphQL Username graphql-password: base64 encoded value of GraphQL Password --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url - parameter: username name: selenium-grid-secret key: graphql-username - parameter: password name: selenium-grid-secret key: graphql-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-node-chrome spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-node-chrome triggers: - type: selenium-grid metadata: browserName: 'chrome' platformName: 'Linux' unsafeSsl: 'true' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.20/scalers/solace-pub-sub-dm.md ================================================ +++ title = "Solace PubSub+ Event Broker - Direct Messaging" availability = "2.18+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker - Direct Messaging" go_file = "solace_dm_scaler" +++ ### Trigger Specification This specification describes the `solace-direct-messaging` trigger that scales based on a Solace PubSub+ Event Broker direct messaging rates for all the clients in a message vpn that matches a common client name prefix. > 💡 **Note:** This trigger is for **Direct messaging** only, it provides the ability to scale the number of client instances automatically based upon transient metrics for shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length), all this metrics exists as long as the clients are connected. If you need to use **Guaranteed messaging** (Solace PubSub+ Event Broker queue) you should use the `solace-event-queue` trigger. ```yaml triggers: - type: solace-direct-messaging metricType: Value metadata: solaceSempBaseURL: "https://solace_broker1:943,https://solace_broker2:943" messageVpn: "message-vpn" clientNamePattern: "client-name-pattern" unsafeSSL: "true" queuedMessagesFactor: '3' aggregatedClientTxMsgRateTarget: '600' aggregatedClientTxByteRateTarget: '0' aggregatedClientAverageTxByteRateTarget: '0' aggregatedClientAverageTxMsgRateTarget: '0' usernameFromEnv: 'ENV_VAR_USER' passwordFromEnv: 'ENV_VAR_PWD' authenticationRef: name: trigger-authentication-ref ``` **Parameter list:** - `solaceSempBaseURL` - Comma separated list of Solace SEMP Endpoint in format: `://:`. (Required) - `messageVpn` - Message VPN hosted on the Solace broker from which the metrics will be collected. (Required) - `clientNamePattern` - Client name pattern that will be used to identify the clients that are consuming from a shared subscription. (Required). It will be used to match all the client names that match the expression: **' \*client-name-pattern\* '** - `unsafeSSL` - Flag to enable unsafe host urls (self signed certificates). (Default: `false`, Optional) - `queuedMessagesFactor` - Flag to to increase weight on queued messages (D-1) and scale faster to avoid discarding messages. (Default: `3`, Optional) - `aggregatedClientTxMsgRateTarget` - Target number messages per second the clients in the shared subscription are expected to consume, if the actual aggregated messages per second number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientTxByteRateTarget` - Target number bytes per second the clients in the shared subscription are expected to consume, if the actual aggregated bytes per second number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientAverageTxByteRateTarget` - Target average number messages per minute the clients in the shared subscription are expected to consume, if the actual aggregated messages per minute number is greater the number of replicas will be increased. (Default: `0`, Optional) - `aggregatedClientAverageTxMsgRateTarget` - Target average number bytes per minute the clients in the shared subscription are expected to consume, if the actual aggregated bytes per minute number is greater the number of replicas will be increased. (Default: `0`, Optional) - `usernameFromEnv` - Environment variable set with SEMP user account. (Optional) - `passwordFromEnv` - Environment variable set with password for the user account. (Optional) **Parameter Requirements:** - Parameters resolving the target host and shared subscription are all **required:** `solaceSempBaseURL`, `messageVpn`, `clientNamePattern` - **At least** one of `aggregatedClientTxMsgRateTarget`, `aggregatedClientTxByteRateTarget`, `aggregatedClientAverageTxByteRateTarget` or `aggregatedClientAverageTxMsgRateTarget` is **required**. If more than one target values are present, calculation is done for each metric and the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) For more details please see [Horizontal Pod Autoscaling - Algorithm details](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) The `solace-direct-messaging` Scaler polls the Solace SEMP REST API to get transient metrics from connected clients. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the trigger to function. These values can be set in several different ways: - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 3 cooldownPeriod: 60 #Always > 0 because is direct messaging! minReplicaCount: 1 maxReplicaCount: 20 advanced: restoreToOriginalReplicaCount: true horizontalPodAutoscalerConfig: behavior: scaleDown: #The stabilization window is used to restrict the flapping of replica count when the metrics used for scaling keep fluctuating. #The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale. #All desired states from the past 1 minutes (60secs) will be considered stabilizationWindowSeconds: 60 #Policy (Pods) allows at most 1 replicas to be scaled down in 10 seconds. policies: - type: Pods value: 1 #Indicates the length of time in the past for which the policy must hold true periodSeconds: 10 scaleUp: stabilizationWindowSeconds: 0 #Policy (Pods) allows at most 3 replicas to be scaled up in 3 seconds. policies: - type: Pods value: 5 periodSeconds: 3 selectPolicy: Max triggers: - type: solace-direct-messaging #we don’t want to take the average of the given metric across all replicas, just the value metricType: Value metadata: solaceSempBaseURL: "https://broker1.messaging.solace.cloud:943,https://broker2.messaging.solace.cloud:943" messageVpn: "consumer_vpn" #all the clients that match this client name pattern will be considered for metric gathering clientNamePattern: "direct-messaging-simple" #to be able to use self signed certs unsafeSSL: "false" #to increase weight on queued messages and scale faster #if there are messages queued means we are behind queuedMessagesFactor: '3' #Metrics aggregatedClientTxMsgRateTarget: '600' aggregatedClientTxByteRateTarget: '0' aggregatedClientAverageTxByteRateTarget: '0' aggregatedClientAverageTxMsgRateTarget: '0' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.20/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" category = "Messaging" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. **Note:** This trigger is for **Guaranteed messaging** (Solace PubSub+ Event Broker queue) only, it provides the ability to scale the number of client instances automatically based upon metrics for a Solace PubSub+ Event Broker queue. If you need to use **Direct messaging**, shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length) you should use the `solace-direct-messaging` trigger. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) messageReceiveRateTarget: '50' ### Messages/second over last 1 minute interval activationMessageCountTarget: '10' activationMessageSpoolUsageTarget: '5' ### Megabytes (MB) activationMessageReceiveRateTarget: '1' ### Messages/second over last 1 minute interval username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint comma-separated host list in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageReceiveRateTarget` - Target number of messages/second manageable by a replica. - `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **solaceSempBaseURL** can contain either a single URL or a comma-separated list of URLs. If multiple URLs are provided, the scaler will iterate over the list until it is both able to connect the broker successfully AND the broker's messageVpn is in the **UP** state. All brokers in the list will share the same authentication configuration. This feature was primarily added to support Solace's Disaster Recovery Replication feature. - **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways: - `username` and `password` may be set directly in the trigger metadata - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time. **Important Notes about Metric Configuration:** > 💡 **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count` > 💡 **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period. > 💡 **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric. > 💡 **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state. >> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant. > 💡 **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog. > 💡 **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: ## Connection Details solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 ## Scaler Details, average values per replica messageCountTarget: '50' messageSpoolUsageTarget: '100000' messageReceiveRateTarget: '20' ## Activation - Scale from 0 replicas to active workload if one of the conditions is met activationMessageCountTarget: '5' activationMessageSpoolUsageTarget: '2' activationMessageReceiveRateTarget: '5' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.20/scalers/solarwinds.md ================================================ +++ title = "SolarWinds" availability = "v2.18+" maintainer = "Community" description = "Scale applications based on metrics from SolarWinds." go_file = "solarwinds_scaler" +++ ### Trigger Specification This specification describes the `solarwinds` trigger that scales based on metrics from SolarWinds. ```yaml triggers: - type: solarwinds metadata: host: https://api.na-01.cloud.solarwinds.com targetValue: "1" activationValue: "3" metricName: "k8s.pod.cpu.usage.seconds.rate" aggregation: "AVG" intervalS: "60" filter: "k8s.deployment.name:my-deployment" ``` **Parameter list:** - `host` - The SolarWinds API endpoint. (Example: `https://api.na-01.cloud.solarwinds.com`) - `targetValue` - Value to reach to start scaling. (This value can be an integer or float) - `activationValue` - Target value for activating the scaler. (Optional, Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds)) - `metricName` - The name of the metric to monitor. - `aggregation` - The aggregation method to use. (Values: `COUNT`, `MIN`, `MAX`, `AVG`, `SUM`, `LAST`) - `intervalS` - The interval in seconds for the metric collection. - `filter` - The filter to apply to the metric data. (Optional, Examples below) - `key1:value1 key2:value2` - Search using key values pairs with a delimiting space for an implicit AND - `key:[value1,value2]` - Search using IN operator (key equals value1 or value2) - `key:~value` - Search using CONTAINS operator - `key>value1 key”, “<“, “<=”, “>=”) (key between value1 and value2) - `NOT key:""` - Search using NOT operator and EMPTY value (key is not empty) - `entities(attribute:value)` - search using attributes of entities related to the metric data (metric values associated with entity having attribute equals value) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing the necessary credentials. **Credential based authentication:** - `apiToken` - The API token for accessing SolarWinds Observability. See [doc](https://documentation.solarwinds.com/en/success_center/observability/content/settings/api-tokens.htm) for more information. ### Example Here is an example of a SolarWinds Scaler with authentication: ```yaml apiVersion: v1 kind: Secret metadata: name: solarwinds-secret namespace: default data: apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solarwinds-auth namespace: default spec: secretTargetRef: - parameter: apiToken name: solarwinds-secret key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solarwinds-scaledobject namespace: default spec: scaleTargetRef: name: nginx pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 2 triggers: - type: solarwinds authenticationRef: name: solarwinds-auth metadata: host: https://api.na-01.cloud.solarwinds.com targetValue: "3" activationValue: "3" metricName: "k8s.pod.cpu.usage.seconds.rate" aggregation: "AVG" intervalS: "60" filter: "k8s.deployment.name:my-deployment" ``` ================================================ FILE: content/docs/2.20/scalers/solr.md ================================================ +++ title = "Solr" availability = "v2.11+" maintainer = "Community" category = "Metrics" description = "Scale applications based on Solr query results." go_file = "solr_scaler" +++ ### Trigger Specification This specification describes the solr trigger that scales based on the outputs of a Solr query. ```yaml triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" activationTargetQueryValue : "3" ``` **Parameter list:** - `host` - The hostname for connecting to the Solr service. - `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional) - `collection` - Your collection name on Solr. - `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate by using a password via TriggerAuthentication configuration. **Credential based authentication:** - `username` - Username for configured user to login to the Solr instance. - `password` - Password for configured user to login to the Solr instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: solr-secret type: Opaque data: solr_username: SOLR_USERNAME solr_password: SOLR_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-solr spec: secretTargetRef: - parameter: username name: solr-secret key: solr_username - parameter: password name: solr-secret key: solr_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solr-scaledobject spec: scaleTargetRef: name: nginx-deploy triggers: - type: solr metadata: host: "http://solr-service.solr-ns.svc.cluster.local:8983" query: "*:*" collection: "my_core" targetQueryValue: "1" authenticationRef: name: trigger-auth-solr ``` ================================================ FILE: content/docs/2.20/scalers/splunk-observability.md ================================================ +++ title = "Splunk Observability" availability = "v2.18+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk Observability Cloud metrics." go_file = "splunk_observability_scaler" +++ ### Trigger Specification This specification describes the `splunk-observability` trigger that scales based on the result of a metric series queried from the Splunk Observability Cloud platform with a [SignalFlow query](https://dev.splunk.com/observability/docs/signalflow/). ```yaml triggers: - type: splunk-observability metadata: # Required: SignalFlow query to retrieve the desired metric time series query: "data('demo.trans.latency').max().publish()" # Required: Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds duration: "10" # Required: Threshold to reach to start scaling targetValue: "400.1" # Required: Target value for activating the scaler activationTargetValue: "1.1" # Required: Specifies how the Metrics Time Series should be processed, options are "min" (minimum value), "max" (maximum value), and "avg" (average value) queryAggregator: "avg" ``` **Parameter list:** - `query` - SignalFlow query for querying the desired metrics. - `duration` - Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds. - `targetValue` - Threshold to reach to start scaling. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `queryAggregator` - When querying metrics from Splunk Observability Cloud, initially a Metric Time Series (MTS) is returned, a list consisting of several datapoints. The 'queryAggregator' specifies how this series of metrics should be "rolled up". Valid values for this field are "avg", which returns the average, "min", which returns the minimum of the metrics in the series, and "max", which returns the maximum value. **Parameter list:** - `accessToken` - Splunk Observability Cloud Access Token. - `realm` - Splunk Observability Cloud Realm. ## Configuration Example The following example shows how to scale a simple NGINX employment with the help of KEDA and the Splunk Observability Cloud scaler: #### Simple NGINX employment ```yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 ``` #### Authentication ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-secrets data: accessToken: realm: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-splunk-secret spec: secretTargetRef: - parameter: accessToken name: splunk-secrets key: accessToken - parameter: realm name: splunk-secrets key: realm ``` #### KEDA Scaler ```yaml --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: splunk-observability metricType: Value metadata: query: "data('demo.trans.count', filter=filter('demo_host', 'server6'), rollup='rate').sum(by=['demo_host']).publish()" duration: "10" queryValue: "400.1" activationQueryValue: "1.1" queryAggregator: "max" # 'min', 'max', or 'avg' authenticationRef: name: keda-trigger-auth-splunk-secret ``` ================================================ FILE: content/docs/2.20/scalers/splunk.md ================================================ +++ title = "Splunk" availability = "v2.15+" maintainer = "Community" category = "Data & Storage" description = "Scale applications based on Splunk saved search results." go_file = "splunk_scaler" +++ ### Trigger Specification This specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches). The trigger always requires the following information: ```yaml triggers: - type: splunk metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "1" activationValue: "10" savedSearchName: my-saved-search-name valueField: count ``` **Parameter list:** - `host` - Search API host and port. Example: `https://localhost:8089`. - `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `"true"`, `"false"`, Default: `"false"`, Optional) - `targetValue` - Value to reach to start scaling (This value can be a integer or float). - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). - `savedSearchName` - Name of saved search that returns metric data for scaling. - `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`. ### Authentication Parameters You can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication. > **Note:** > > `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API. **Parameter list:** - `username` - Splunk username authorized to access the search API. - `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`. - `password` - Password for supplied `username`. Conflicts with `apiToken`. The user will need access to the saved search. ### Examples ### Username/password ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### API Token ```yaml --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # admin apiToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: apiToken name: splunk-creds key: apiToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 targetValue: "11" activationValue: "15" savedSearchName: my-saved-search-name valueField: count ``` ### Full example using Splunk deployment ```yaml --- apiVersion: v1 kind: ConfigMap metadata: name: splunkconf data: default.yml: | splunk: conf: - key: savedsearches value: directory: /opt/splunk/etc/users/admin/search/local content: my-saved-search-name: action.email.useNSSubject: 1 action.webhook.enable_allowlist: 0 alert.track: 0 cron_schedule: '*/1 * * * *' dispatch.earliest_time: -15m dispatch.latest_time: now display.general.type: statistics display.page.search.tab: statistics display.visualizations.show: 0 enableSched: 1 request.ui_dispatch_app: search request.ui_dispatch_view: search search: index=_internal | tail | stats count --- apiVersion: v1 kind: Secret metadata: name: splunk-creds data: username: YWRtaW4= # "admin" password: cGFzc3dvcmQ= # "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: splunk-auth spec: secretTargetRef: - parameter: username name: splunk-creds key: username - parameter: password name: splunk-creds key: password --- apiVersion: v1 kind: Service metadata: name: splunk spec: ports: - port: 8000 targetPort: web name: web-svc - port: 8089 targetPort: 8089 name: api-svc selector: app: splunk --- apiVersion: apps/v1 kind: Deployment metadata: name: splunk namespace: default spec: replicas: 1 selector: matchLabels: app: splunk template: metadata: labels: app: splunk spec: containers: - name: splunk image: splunk/splunk:9.2 ports: - containerPort: 8000 name: web - containerPort: 8089 name: api env: - name: SPLUNK_START_ARGS value: --accept-license - name: SPLUNK_PASSWORD value: password volumeMounts: - name: splunkconf-volume mountPath: /tmp/defaults volumes: - name: splunkconf-volume configMap: name: splunkconf --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 8080 --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: splunk-scaledobject spec: pollingInterval: 15 minReplicaCount: 1 maxReplicaCount: 3 scaleTargetRef: name: nginx triggers: - type: splunk authenticationRef: name: splunk-auth metadata: host: https://splunk.default.svc.cluster.local:8089 unsafeSsl: "true" targetValue: "5" activationValue: "5" savedSearchName: my-saved-search-name valueField: count ``` ================================================ FILE: content/docs/2.20/scalers/sumologic.md ================================================ +++ title = "Sumo Logic" availability = "v2.18+" maintainer = "Community" category = "Monitoring & Analytics" description = "Scale applications based on Sumo Logic logs searches and metrics queries." go_file = "sumologic_scaler" +++ ## Trigger Specification This specification describes the `sumologic` trigger that scales based on Sumo Logic logs searches and metrics queries. The scaler supports three different query types: - **`logs`** - Scale based on Sumo Logic logs query results - **`metrics`** - Scale based on single Sumo Logic metrics query results - **`metrics` (multi-query)** - Scale based on multiple combined Sumo Logic metrics queries Here are examples of the different trigger configurations: **Logs Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" # Sumo Logic API endpoint queryType: "logs" # Type must be "logs" query: "_view=my_view | count" # Your Sumo Logic logs query resultField: "_count" # Field to extract value from timerange: "15m" # Lookback window timezone: "Asia/Kolkata" # Timezone (e.g., Asia/Kolkata) queryAggregator: "Max" # Aggregation method: Latest, Avg, Sum, Count, Min, Max threshold: "1000" # Threshold for scaling authenticationRef: name: keda-trigger-auth-sumologic ``` **Single Metrics Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "metrics" query: "metric=cpu.usage | avg" quantization: "15s" rollup: "Max" timerange: "15m" timezone: "Asia/Kolkata" queryAggregator: "Max" threshold: "50" maxRetries: "3" # Optional: Maximum retry attempts authenticationRef: name: keda-trigger-auth-sumologic ``` **Multi-Metrics Query Example:** ```yaml triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "metrics" query.A: "metric=requests_total | rate" query.B: "metric=request_capacity" query.C: "(#A / #B) * 100 along service" resultQueryRowID: "C" # Which query result to extract quantization: "15s" rollup: "Max" timerange: "15m" timezone: "Asia/Kolkata" queryAggregator: "Max" threshold: "75" authenticationRef: name: keda-trigger-auth-sumologic ``` **Parameter list:** **Common Parameters:** - `host` - Sumo Logic API endpoint URL (Based on your Geo). - `queryType` - Type of query. (Values: `logs`, `metrics`) - `query` - Sumo Logic query (for single queries). - `timerange` - Time range to evaluate the query. - `timezone` - Timezone for query execution. (Default: `UTC`, Optional) - `queryAggregator` - Aggregation method. (Values: `Latest`, `Avg`, `Sum`, `Count`, `Min`, `Max`, Default: `Avg`, Optional) - `threshold` - Target value for scaling. - `maxRetries` - Maximum number of retry attempts for API requests. (Default: `3`, Optional) **Logs Query Specific Parameters:** - `resultField` - Field from query results to extract the scaling metric. (Required when `queryType` is `logs`) - `logsPollingInterval` - Polling interval for log search job. (Default: `1s`, Optional) **Metrics Query Specific Parameters:** - `quantization` - Granularity of data points. (Required when `queryType` is `metrics`) - `rollup` - Metrics rollup type. (Values: `Avg`, `Sum`, `Min`, `Max`, `Count`, Default: `Avg`, Optional) **Multi-Metrics Query Specific Parameters:** - `query.A`, `query.B`, `query.C` etc - Multi-stage queries, where later queries can refer to earlier ones. (Required for multi-metrics queries) - `resultQueryRowID` - Which final query (`A`, `B`, `C`, etc.) to use for scaling. (Required for multi-metrics queries) ## Authentication Parameters You must configure a `TriggerAuthentication` resource to authenticate with Sumo Logic. **Prerequisites:** - A Sumo Logic Access ID and Access Key Authentication is handled through a Kubernetes `Secret` combined with a `TriggerAuthentication`: ```yaml apiVersion: v1 kind: Secret metadata: name: sumologic-auth-secret data: accessID: accessKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-sumologic spec: secretTargetRef: - parameter: accessID name: sumologic-auth-secret key: accessID - parameter: accessKey name: sumologic-auth-secret key: accessKey ``` ### Example Here is a complete example that demonstrates autoscaling based on Sumo Logic logs query: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: sumologic-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: sumologic metadata: host: "https://api.sumologic.com" queryType: "logs" query: "_view=error_logs | count" resultField: "_count" timerange: "5m" threshold: "100" authenticationRef: name: keda-trigger-auth-sumologic ``` ### Notes - `pollingInterval` controls how often KEDA polls Sumo Logic. - `cooldownPeriod` controls how long KEDA waits before scaling down. - `MetricType:` The scaler supports both `AverageValue` and `Value` metric types. - Ensure that the Sumo Logic user has **appropriate access** to the queries being executed. ================================================ FILE: content/docs/2.20/scalers/temporal.md ================================================ +++ title = "Temporal" availability = "v2.17+" maintainer = "Community" description = "Scale applications based on Temporal task queue." go_file = "temporal_scaler" +++ ### Trigger Specification This specification describes the `temporal` trigger that scales based on a Temporal task queue. ```yaml triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 queueTypes: workflow # optional buildId: 1.0.0 # optional selectAllActive: "false" # optional selectUnversioned: "false" # optional minConnectTimeout: "5" # optional unsafeSsl: "false" # optional tlsServerName: "custom-tls-servername" # optional ``` **Parameter list:** - `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `:`. (Required) - `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional) - `namespace` - The namespace of the temporal service. (Default:`default`, Optional) - `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional) - `taskQueue` - This parameter specifies the task queue name. (Required) - `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional) - `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional) - `selectAllActive` - Include all active versions (Default:`false`, Optional) - `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional) - `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional) - `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional) - `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional) - `tlsServerName` - The custom tls server name (Optional) > 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero. This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog. Consequently, scaling to zero could result in undesirable behavior, such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA). By fine-tuning the configurations, you can prevent premature scaling to zero, ensuring that resources remain available for in-flight tasks or workloads with minimal throughput. **Authentication Parameters:** Temporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication: - `apiKey` - API key for authentication with temporal cloud. (Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: temporal-secret namespace: default type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-temporal namespace: default spec: secretTargetRef: - parameter: apiKey name: temporal-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject namespace: default spec: scaleTargetRef: name: workload-scaledobject pollingInterval: 5 cooldownPeriod: 10 minReplicaCount: 0 maxReplicaCount: 5 advanced: horizontalPodAutoscalerConfig: behavior: scaleDown: stabilizationWindowSeconds: 10 triggers: - type: temporal metadata: namespace: default taskQueue: "workflow_with_single_noop_activity:test" targetQueueSize: "2" activationTargetQueueSize: "0" endpoint: temporal-frontend.temporal.svc.cluster.local:7233 authenticationRef: name: keda-trigger-auth-temporal ``` ================================================ FILE: content/docs/2.20/setupscaler.md ================================================ +++ title = "Setup Autoscaling with KEDA" weight = 500 description = "Procedure to Setup a Scaler in KEDA" +++ ## Prerequisites 1. **Kubernetes Cluster**: - Ensure you have a running Kubernetes cluster set up and accessible. - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.). 2. **KEDA Installation**: - KEDA needs to be installed on your Kubernetes cluster before you can use it. - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup. - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs. 3. **kubectl**: - The `kubectl` command-line tool is required to interact with your Kubernetes cluster. - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system. - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup. ## Step 1: Identify the Scaler You Need KEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source. 1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers. 2. Identify the scaler that matches the event source you want to use for scaling your application. For example: - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/). > **Note:** > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment. - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**. - If you want to scale based on a cron schedule, you would need the **Cron scaler**. 3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options. ## Step 2: Install the Required Scaler (if needed) Some scalers are part of the core KEDA installation, while others need to be installed separately as add-ons. 1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately. 2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully. - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`. 3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands. ## Step 3: Create a ScaledObject Configuration File KEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger. 1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line. 2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler. 3. Typically, the `ScaledObject` configuration includes the following sections: - `metadata`: Specifies the name and namespace for the `ScaledObject`. - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled. - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds). - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds). - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100). - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings. 4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings. 5. Save the `scaledobject.yaml` file after making the necessary modifications. ## Step 4: Apply the ScaledObject Configuration Once you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`: 1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file. 2. Run the following command to apply the `ScaledObject` configuration: ```bash kubectl apply -f scaledobject.yaml ``` ```plaintext scaledobject.keda.sh/ created ``` 3. Verify that the `ScaledObject` has been created successfully by running: ```bash kubectl get scaledobjects ``` This should display the `ScaledObject` you just created. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` After applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided. ## Step 5: Monitor Scaling Events You can monitor the scaling events and logs generated by KEDA using the following commands: 1. List all `ScaledObjects` in your cluster: ```bash kubectl get scaledobjects ``` This will show you the current state of your `ScaledObject` and the number of replicas. ```plaintext NAME SCALETARGETKIND SCALETARGETNAME MIN MAX TRIGGERS AUTHENTICATION READY ACTIVE FALLBACK AGE Deployment 1 10 cpu True False 10s ``` 2. View the logs of the KEDA operator: ```bash kubectl logs -n keda -l app=keda-operator ``` The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings. ```plaintext {"level":"info","ts":,"logger":"scalehandler","msg":"Successfully scaled deployment","scaledobject.Namespace":"","scaledobject.Name":"","scaler":} ``` ================================================ FILE: content/docs/2.20/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.3/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.3/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.3/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.3/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.3/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.3/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.3/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.3/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.3/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.3/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.3/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interfaces: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. Few things to notice: - Lack of `Close` method as the GRPC connection defines the lifetime of the scaler - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` For `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.3/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml minReplicaCount: 0 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource. --- ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.3/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.3/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.3/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster you can run one of the following: ```sh helm uninstall keda -n keda ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.3.0`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.3.0/keda-2.3.0.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.3.0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.3.0 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.3.0`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.3.0/keda-2.3.0.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.3.0.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.3.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.3/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.3/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.3/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.3/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) ================================================ FILE: content/docs/2.3/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.3 has been tested on Kubernetes v1.16.0 or above. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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.This is only supported as of KEDA v2.6 if you are using our Helm chart. | ## 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: ```shell export KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` And on Windows Powershell, you'd use this command: ```shell $env:KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` All applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported. ================================================ FILE: content/docs/2.3/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted`| `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.3/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.3/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.3/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest allowIdleConsumers: 'false' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.3/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.3/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName dimensionName: QueueName # Required: Dimension Value - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Metric Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.3/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.3/concepts/authentication/). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.3/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) > For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.3/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `""`) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.3/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: kube_pod_status_ready metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.3/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Required - Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolID` - Id of the queue. - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.3/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.3/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on of the `blobContainerName`, `blobPrefix` and `blobDelimiter`. For example: **azure-blob-functions-blob-myprefix-example**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.3/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.3/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.3/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.3/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.3/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.3/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.3/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.3/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Password Authentication:** - `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager. - `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.3/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.3/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.3/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.3/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.3/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `password` - Password for the configured user to login to MongoDB server. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.3/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. The default for MSSQL is 1433. - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the `database` value (if specified), or the `host` value, or will be in the form `mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.3/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `password` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.3/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/2.3/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: 1250 #required timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.3/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.3/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.3/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Metric name to use. - `query` - Query to run. - `threshold` - Value to start scaling for. ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.3/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100" # message backlog or publish/sec. target per instance queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.3/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.3/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.3/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.3/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.3/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.4/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.4/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.4/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.4/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.4/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.4/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.4/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.4/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.4/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.4/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.4/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Built-in scalers implement one of the following go interfaces: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true. - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto): ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. Few things to notice: - Lack of `Close` method as the GRPC connection defines the lifetime of the scaler - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. For example the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef` ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` For `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler: #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project: {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day `ScaledObject` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `main.go` ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found here: https://github.com/kedacore/external-scaler-samples `Services/ExternalScalerService.cs` ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} `index.js` ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.4/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- ```yaml idleReplicaCount: 0 # Optional. Must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It is **not** supported by the CPU & memory scalers and will assume that fallback is disabled in those cases. This is because it only supports scalers that present their target as an `AverageValue` metric. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.4/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.4/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.4/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects,scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.4.0`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.4.0/keda-2.4.0.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.4.0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.4.0 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.4.0`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.4.0/keda-2.4.0.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.4.0.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.4.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.4/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.4/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.4/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.4/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) ================================================ FILE: content/docs/2.4/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.4 has been tested on Kubernetes v1.16.0 or above. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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.This is only supported as of KEDA v2.6 if you are using our Helm chart. | ## 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: ```shell export KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` And on Windows Powershell, you'd use this command: ```shell $env:KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` All applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported. ## 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 Flag | Client Config Setting | Default Value | Description | | -------------- | --------------------- | ------------- | -------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | ================================================ FILE: content/docs/2.4/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted`| `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.4/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ## How to get metric when multiple ScaledObjects have the same metric name KEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown: ``` Error from server: exactly one ScaledObject should match label ``` In this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels} ``` Once you have the selector, you have to add it to your query string as following: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}" ``` ================================================ FILE: content/docs/2.4/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.4/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.4/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest allowIdleConsumers: 'false' version: 1.0.0 ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.4/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.4/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName dimensionName: QueueName # Required: Dimension Value - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Metric Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.4/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.4/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) > For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.4/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `""`) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.4/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.4/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Required - Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolID` - Id of the queue. - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.4/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.4/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on of the `blobContainerName`, `blobPrefix` and `blobDelimiter`. For example: **azure-blob-functions-blob-myprefix-example**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.4/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.4/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.4/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.4/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.4/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.4/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Optional - Default is 5 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.4/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.4/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Password Authentication:** - `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager. - `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.4/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.4/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the amount of pods which matches the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.4/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.4/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.4/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.4/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `password` - Password for the configured user to login to MongoDB server. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.4/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. The default for MSSQL is 1433. - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the `database` value (if specified), or the `host` value, or will be in the form `mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.4/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `password` - Password for configured user to login to MySQL database variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.4/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters **Connection Authentication:** Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: gonuts spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` ================================================ FILE: content/docs/2.4/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: 1250 #required timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. **Password Authentication:** - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. **Application Credentials Authentication:** - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.4/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. **Password Authentication:** - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. **Application Credentials Authentication:** - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.4/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a postgresql query The Postgresql scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for postgreSQL database. **Password Authentication:** - `password` - Password for configured user to login to postgreSQL database variables. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.4/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required serverAddress: http://:9090 metricName: http_requests_total query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Metric name to use. - `query` - Query to run. - `threshold` - Value to start scaling for. ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.4/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100" # message backlog or publish/sec. target per instance queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.4/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.4/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.4/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Password Authentication:** - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.4/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: **Password Authentication:** - `password` - Redis password to authenticate with. #### Using password authentication Use the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-password type: Opaque data: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: password name: redis-streams-password # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.4/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue. The scaler creates one browser node per pending request in session queue. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly, for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ================================================ FILE: content/docs/2.4/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.4/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.5/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.5/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.5/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.5/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.5/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.5/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.5/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.5/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.5/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.5/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.5/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam | gcp # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.5/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec). - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.5/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It is **not** supported by the CPU & memory scalers and will assume that fallback is disabled in those cases. This is because it only supports scalers that present their target as an `AverageValue` metric. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.5/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rolloutStrategy: default # Optional. Default: default. Which Rollout Strategy KEDA will use. ``` This optional property specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. \ On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.5/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.5/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects,scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.5.0`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.5.0/keda-2.5.0.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.5.0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.5.0 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.5.0`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.5.0/keda-2.5.0.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.5.0.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.5.0 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.5/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.5/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Metrics Adapter The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.5/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.5/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) ================================================ FILE: content/docs/2.5/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.5 has been tested on Kubernetes v1.17.0 or above. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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: ```shell export KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` And on Windows Powershell, you'd use this command: ```shell $env:KEDA_HTTP_DEFAULT_TIMEOUT=1000 ``` All applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported. ## 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 Flag | Client Config Setting | Default Value | Description | | -------------- | --------------------- | ------------- | -------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | -------------- | ------------- | ----------------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | | KEDA_METRICS_CTRL_MAX_RECONCILES | Metrics Server | 1 | MetricsScaledObjectReconciler | ================================================ FILE: content/docs/2.5/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted`| `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.5/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ## How to get metric when multiple ScaledObjects have the same metric name KEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown: ``` Error from server: exactly one ScaledObject should match label ``` In this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels} ``` Once you have the selector, you have to add it to your query string as following: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}" ``` ================================================ FILE: content/docs/2.5/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.5/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.5/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed the number of partitions on a topic and will not exceed `maxReplicaCount`. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest allowIdleConsumers: 'false' version: 1.0.0 ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.5/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.5/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName dimensionName: QueueName # Required: Dimension Value - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiply of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, that it must be supported by Cloudwatch. More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit is going to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `Average`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: keda-aws-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: keda-aws-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.5/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.5/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) > For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: AWS_SECRET_ACCESS_KEY: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.5/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `""`) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.5/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.5/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Required - Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolID` - Id of the queue. - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.5/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.5/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.5/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.5/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). - `metricName` - Name to assign to the metric. (Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.5/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.5/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.5/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. - `parameters` - Parameters that will be used by the search template. It supports multiples param separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password authentication. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.5/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.5/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.5/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub authenticationRef: gcp-pubsub-credentials # Required metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge subscriptionName: "mysubscription" # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. `authenticationRef` defines how KEDA connect to Google Cloud Platform, to collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. You can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`. The mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`. The `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can configure authorization for a `ScaledObject` either directly using credentials in `credentialsFromEnv` or using an `authenticationRef` referencing a `TriggerAuthentication` CRD which configures authorization. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to `gcp` on the `TriggerAuthentication` and the pod's [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) or node's (default) service account must be configured correctly. **Credential based authentication via TriggerAuthentication:** - `secretTargetRef` - Needs to be set on the `TriggerAuthentication`, with `parameter=GoogleApplicationCredentials` and `name` must reference a Secret in which `key` is the key containing the JSON ServiceAccount value. **Credential based authentication via ScaledObject:** - `credentialsFromEnv` - Needs to be set on the `ScaledObject`. ### Examples To use the GCP default authentication, you need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: gcp-pubsub-credentials spec: podIdentity: provider: gcp # Required --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionName: "input" # Required authenticationRef: name: gcp-pubsub-credentials ``` Alternatively, you can configure the credentials in a secret, via the `TriggerAuthentication`: ```yaml apiVersion: v1 kind: Secret metadata: name: pubsub-secret data: GOOGLE_APPLICATION_CREDENTIALS_JSON: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: gcp-pubsub-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionName: "input" # Required authenticationRef: name: gcp-pubsub-credentials # Required ``` The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.5/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '100' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique - `query` - Query to run. - `threshold` - Value to start scaling for. - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.5/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.5/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.5/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.5/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the amount of pods which matches the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.5/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.5/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.5/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.5/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.5/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.5/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.5/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.5/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: 1250 #required timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.5/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.5/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.5/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique. - `query` - Query to run. - `threshold` - Value to start scaling for. ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.5/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100" # message backlog or publish/sec. target per instance queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.5/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.5/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.5/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.5/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.5/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.5/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.5/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue. The scaler creates one browser node per pending request in session queue. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly, for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ================================================ FILE: content/docs/2.5/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" aliases = ["solace"] +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.5/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.6/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.6/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.6/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.6/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.6/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.6/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.6/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.6/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.6/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.6/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.6/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam | gcp # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.6/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec). - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.6/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It is **not** supported by the CPU & memory scalers and will assume that fallback is disabled in those cases. This is because it only supports scalers that present their target as an `AverageValue` metric. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.6/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rolloutStrategy: default # Optional. Default: default. Which Rollout Strategy KEDA will use. ``` This optional property specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. \ On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.6/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.6/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects,scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.6.1`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.6.1/keda-2.6.1.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.6.1.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.6.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.6.1`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.6.1/keda-2.6.1.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.6.1.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.6.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.6/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.6/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Metrics Adapter The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.6/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.6/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) ================================================ FILE: content/docs/2.6/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.6 has been tested on Kubernetes v1.17.0 through v1.25.0. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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. ## 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 Flag | Client Config Setting | Default Value | Description | | -------------- | --------------------- | ------------- | -------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | -------------- | ------------- | ----------------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | | KEDA_METRICS_CTRL_MAX_RECONCILES | Metrics Server | 1 | MetricsScaledObjectReconciler | ## 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: ```yaml --- 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](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA). You should also make sure that `insecureSkipTLSVerify` is not set to `true`. ```yaml --- spec: service: namespace: keda name: keda-metrics-apiserver port: 443 group: external.metrics.k8s.io version: v1beta1 caBundle: >- YOURCABUNDLE... groupPriorityMinimum: 100 versionPriority: 100 ``` ================================================ FILE: content/docs/2.6/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | |-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------| | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted`| `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.6/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ## How to get metric when multiple ScaledObjects have the same metric name KEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown: ``` Error from server: exactly one ScaledObject should match label ``` In this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels} ``` Once you have the selector, you have to add it to your query string as following: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}" ``` ================================================ FILE: content/docs/2.6/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.6/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.6/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.6/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest allowIdleConsumers: 'false' version: 1.0.0 ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.6/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.6/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Required: Dimension Name - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName dimensionName: QueueName # Required: Dimension Value - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiply of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, that it must be supported by Cloudwatch. More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit is going to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `Average`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.6/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.6/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) > For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.6/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure Active Directory pod-managed identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.6/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `""`) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.6/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId) The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.6/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.6/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215) # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.6/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.6/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.6/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). - `metricName` - Name to assign to the metric. (Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.6/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.6/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.6/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7" type: "global" age: "120" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling. - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: (Global or Average). Whether the target value is global or average per pod. Default: Average type: "Global" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ================================================ FILE: content/docs/2.6/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password authentication. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.6/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.6/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.6/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform Pub/Sub." go_file = "gcp_pub_sub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub. ```yaml triggers: - type: gcp-pubsub authenticationRef: gcp-pubsub-credentials # Required metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge subscriptionName: "mysubscription" # Required ``` The Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. `authenticationRef` defines how KEDA connect to Google Cloud Platform, to collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. You can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`. The mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`. The `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can configure authorization for a `ScaledObject` either directly using credentials in `credentialsFromEnv` or using an `authenticationRef` referencing a `TriggerAuthentication` CRD which configures authorization. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to `gcp` on the `TriggerAuthentication` and the pod's [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) or node's (default) service account must be configured correctly. **Credential based authentication via TriggerAuthentication:** - `secretTargetRef` - Needs to be set on the `TriggerAuthentication`, with `parameter=GoogleApplicationCredentials` and `name` must reference a Secret in which `key` is the key containing the JSON ServiceAccount value. **Credential based authentication via ScaledObject:** - `credentialsFromEnv` - Needs to be set on the `ScaledObject`. ### Examples To use the GCP default authentication, you need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: gcp-pubsub-credentials spec: podIdentity: provider: gcp # Required --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionName: "input" # Required authenticationRef: name: gcp-pubsub-credentials ``` Alternatively, you can configure the credentials in a secret, via the `TriggerAuthentication`: ```yaml apiVersion: v1 kind: Secret metadata: name: pubsub-secret data: GOOGLE_APPLICATION_CREDENTIALS_JSON: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: gcp-pubsub-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionName: "input" # Required authenticationRef: name: gcp-pubsub-credentials # Required ``` The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.6/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '100' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique - `query` - Query to run. - `threshold` - Value to start scaling for. - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.6/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.6/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.6/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.6/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.6/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.6/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metadata: # Required type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metadata: type: Utilization # Allowed types are 'Utilization' or 'AverageValue' value: "50" ``` ================================================ FILE: content/docs/2.6/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.6/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.6/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA). > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.6/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetAverageValue` in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.6/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.6/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: '100' ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetAverageValue` in the HPA configuration. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: account: '1234567' region: "US" nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.6/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: 1250 #required timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.6/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.6/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.6/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.6/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique. - `query` - Query to run. - `threshold` - Value to start scaling for. - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.6/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100" # message backlog or publish/sec. target per instance queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.6/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.6/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.6/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.6/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.6/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.6/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.6/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue. The scaler creates one browser node per pending request in session queue. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly, for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ================================================ FILE: content/docs/2.6/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" aliases = ["solace"] +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.6/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.7/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.7/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.7/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.7/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.7/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. ================================================ FILE: content/docs/2.7/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently pod identity providers are not supported for key vault. You need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Required. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.7/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.7/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.7/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.7/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.7/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.7/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | aws-eks | aws-kiam | gcp # Optional. Default: none secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Required. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.7/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec). - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.7/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" ``` The presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.7/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives on the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 ``` --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rolloutStrategy: default # Optional. Default: default. Which Rollout Strategy KEDA will use. ``` This optional property specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. \ On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.7/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.7/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects,scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.7.1`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.7.1/keda-2.7.1.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.7.1.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.7.1 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.7.1`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.7.1/keda-2.7.1.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.7.1.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.7.1 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.7/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.7/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Metrics Adapter The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.7/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.7/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) ================================================ FILE: content/docs/2.7/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.7 has been tested on Kubernetes v1.17.0 through v1.25.0. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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 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. ```yaml - 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 Flag | Client Config Setting | Default Value | Description | | -------------- | --------------------- | ------------- | -------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | -------------- | ------------- | ----------------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | | KEDA_METRICS_CTRL_MAX_RECONCILES | Metrics Server | 1 | MetricsScaledObjectReconciler | ## 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: ```yaml --- 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](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA). You should also make sure that `insecureSkipTLSVerify` is not set to `true`. ```yaml --- spec: service: namespace: keda name: keda-metrics-apiserver port: 443 group: external.metrics.k8s.io version: v1beta1 caBundle: >- YOURCABUNDLE... groupPriorityMinimum: 100 versionPriority: 100 ``` ================================================ FILE: content/docs/2.7/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.7/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ## How to get metric when multiple ScaledObjects have the same metric name KEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown: ``` Error from server: exactly one ScaledObject should match label ``` In this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels} ``` Once you have the selector, you have to add it to your query string as following: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}" ``` ================================================ FILE: content/docs/2.7/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.7/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.7/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.7/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' version: 1.0.0 ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.7/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.7/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiply of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, that it must be supported by Cloudwatch. More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit is going to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `Average`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.7/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Required: tableName tableName: myTableName # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `tableName` - The target table where the scaler execute the query. - `targetValue` - The target value for the number of items retrieved by the query. - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.7/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.7/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) > For the purposes of scaling, "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` ================================================ FILE: content/docs/2.7/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure Active Directory pod-managed identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.7/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well clientSecret: t0p-s3cret # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `clientSecret` - Password of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure Active Directory pod-managed identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.7/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.7/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.7/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Example ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" authenticationRef: name: pipeline-trigger-auth ``` ================================================ FILE: content/docs/2.7/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.7/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.7/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.7/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `metricName` - Name to assign to the metric. (Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.7/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; Allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` ================================================ FILE: content/docs/2.7/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.7/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7" type: "global" # Deprecated in favor of trigger.metricType age: "120" metricUnavailableValue: "0" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling. - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ================================================ FILE: content/docs/2.7/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password authentication. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.7/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.7/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.7/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. You can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`. The mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`. The `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.7/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.7/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.7/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '100' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique - `query` - Query to run. - `threshold` - Value to start scaling for. - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.7/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "100" minMetricValue: "1" ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. - `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.7/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.7/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.7/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.7/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.7/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` ================================================ FILE: content/docs/2.7/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.7/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.7/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.7/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.7/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.7/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: '100' ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.7/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: 1250 #required timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.7/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.7/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.7/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.7/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # Optional. X-Scope-OrgID header for Cortex. ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique. - `query` - Query to run. - `threshold` - Value to start scaling for. - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - The `X-Scope-OrgID` header to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.7/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100" # message backlog or publish/sec. target per instance queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.7/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.7/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.7/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.7/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.7/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.7/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.7/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly, for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ================================================ FILE: content/docs/2.7/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.7/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.8/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.8/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.8/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.8/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.8/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.8/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ================================================ FILE: content/docs/2.8/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently pod identity providers are not supported for key vault. You need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Required. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.8/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.8/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.8/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.8/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.8/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.8/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Available authentication providers for KEDA Authentication parameters can be retrieved from a variety of authentication providers in KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.8/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go type Scaler interface { GetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error) GetMetricSpecForScaling() []v2beta2.MetricSpec IsActive(ctx context.Context) (bool, error) Close() error } type PushScaler interface { Scaler Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 4 methods: - `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec). - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition. - `IsActive` maps to the `IsActive` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.8/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" ``` The presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition. ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.8/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.8/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.8/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.8.2`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.8.2/keda-2.8.2.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2..0.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.8.2 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.8.2`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.8.2/keda-2.8.2.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.8.2.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.8.2 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.8/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.8/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Metrics Adapter The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ================================================ FILE: content/docs/2.8/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.8/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) ================================================ FILE: content/docs/2.8/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA v2.8 has been tested on Kubernetes v1.17.0 through v1.25.0. ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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 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. ```yaml - 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 Flag | Client Config Setting | Default Value | Description | | -------------- | --------------------- | ------------- | -------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | -------------- | ------------- | ----------------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | | KEDA_METRICS_CTRL_MAX_RECONCILES | Metrics Server | 1 | MetricsScaledObjectReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## 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: ```yaml --- 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](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA). You should also make sure that `insecureSkipTLSVerify` is not set to `true`. ```yaml --- spec: service: namespace: keda name: keda-metrics-apiserver port: 443 group: external.metrics.k8s.io version: v1beta1 caBundle: >- YOURCABUNDLE... groupPriorityMinimum: 100 versionPriority: 100 ``` ================================================ FILE: content/docs/2.8/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.8/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ## How to get metric when multiple ScaledObjects have the same metric name KEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown: ``` Error from server: exactly one ScaledObject should match label ``` In this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels} ``` Once you have the selector, you have to add it to your query string as following: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}" ``` ================================================ FILE: content/docs/2.8/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.8/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.8/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.8/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' version: 1.0.0 ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.8/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.8/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.8/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.8/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Required: tableName tableName: myTableName # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `tableName` - The target table where the scaler execute the query. - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.8/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.8/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. - `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well. - When set to `false` "actual messages" is equal to `ApproximateNumberOfMessages`. When set to `true` "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true) - `awsRegion` - AWS Region for the SQS Queue. - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.8/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.8/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well clientSecret: t0p-s3cret # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `clientSecret` - Password of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.8/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.8/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.8/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored) Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ###Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ================================================ FILE: content/docs/2.8/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.8/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.8/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.8/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" metricName: "test_keyspace" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `metricName` - Name to assign to the metric. (Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.8/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.8/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.8/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" type: "global" # Deprecated in favor of trigger.metricType age: "120" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ================================================ FILE: content/docs/2.8/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password authentication. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.8/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.8/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.8/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge activationValue: "10" # Optional - Default is 0 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. You can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`. The mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`. The `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.8/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100' activationTargetValue: "10" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.8/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.8/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.8/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.8/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.8/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.8/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.8/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.8/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.8/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.8/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.8/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.8/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.8/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" ``` ================================================ FILE: content/docs/2.8/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.8/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.8/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.8/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.8/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.8/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.8/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # Optional. X-Scope-OrgID header for Cortex. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique. - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - The `X-Scope-OrgID` header to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.8/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" description = "Scale applications based on an Apache Pulsar topic subscription." layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Authentication Parameters If TLS is required you should set `tls` to `enable`. If required for your Pulsar configuration, you may also provide a `ca`, `cert` and `key`. `ca`, `cert` and `key` must be specified together. **TLS:** - `tls`: Optional. To enable SSL auth for Pulsar, set this to `enable`. If not set, TLS for Pulsar is not used, Your shoule set this key to trigger metadata. - `ca`: Certificate authority file for TLS client authentication. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. ### Example Your pulsar cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' ``` Your pulsar cluster turn on TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: tls: "enable" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` ================================================ FILE: content/docs/2.8/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.8/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.8/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.8/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.8/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.8/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.8/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) > ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.8/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ================================================ FILE: content/docs/2.8/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) activationMessageCountTarget: '100' activationMessageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.8/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/2.9/_index.md ================================================ +++ title = "The KEDA Documentation" weight = 1 +++ Welcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components. Additions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs). ================================================ FILE: content/docs/2.9/authentication-providers/_index.md ================================================ +++ title = "Authentication Providers" weight = 5 +++ Available authentication providers for KEDA: {{< authentication-providers >}} ================================================ FILE: content/docs/2.9/authentication-providers/aws-eks.md ================================================ +++ title = "AWS EKS Pod Identity Webhook" +++ [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` ================================================ FILE: content/docs/2.9/authentication-providers/aws-kiam.md ================================================ +++ title = "AWS Kiam Pod Identity" +++ [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.9/authentication-providers/azure-ad-pod-identity.md ================================================ +++ title = "Azure AD Pod Identity" +++ Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ================================================ FILE: content/docs/2.9/authentication-providers/azure-ad-workload-identity.md ================================================ +++ title = "Azure AD Workload Identity" +++ [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. ## Considerations about Federations and Overrides The concept of "overrides" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality. Let's clarify this with two examples: ### Case 1 Imagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup: - KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden). - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, KEDA's Managed Service Identity should only be federated with KEDA's service account. ### Case 2 To avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads: - KEDA's identity without access to any Service Bus. - Workload A's identity with access to Service Bus A. - Workload B's identity with access to Service Bus B. - Workload C's identity with access to Service Bus C. In this case, you are overriding the default identity set during installation through the "TriggerAuthentication" option (`.spec.podIdentity.identityId`). Each "ScaledObject" now uses its own "TriggerAuthentication," with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume: - TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault). - TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them). ================================================ FILE: content/docs/2.9/authentication-providers/azure-key-vault.md ================================================ +++ title = "Azure Key Vault secret" +++ You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. Currently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`. Service principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ================================================ FILE: content/docs/2.9/authentication-providers/environment-variable.md ================================================ +++ title = "Environment variable" +++ You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.9/authentication-providers/gcp-workload-identity.md ================================================ +++ title = "GCP Workload Identity" +++ [**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services. You can tell KEDA to use GCP Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: gcp # Optional. Default: none ``` ### Steps to setup Workload Identity If you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled. * You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers. ```shell gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT ``` Replace the following: \ GSA_NAME: the name of the new IAM service account.\ GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account. * Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command: ```shell gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer. * Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account. ```shell gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]" ``` Replace the following: PROJECT_ID: your Google Cloud project ID. \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \ NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \ KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` . * Then you need to annotate the Kubernetes service account with the email address of the IAM service account. ```shell kubectl annotate serviceaccount keda-operator \ --namespace keda \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com ``` Replace the following: \ GSA_NAME: the name of your IAM service account. \ GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. ================================================ FILE: content/docs/2.9/authentication-providers/hashicorp-vault.md ================================================ +++ title = "Hashicorp Vault secret" +++ You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ================================================ FILE: content/docs/2.9/authentication-providers/secret.md ================================================ +++ title = "Secret" +++ You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ================================================ FILE: content/docs/2.9/concepts/_index.md ================================================ +++ title = "KEDA Concepts" description = "What KEDA is and how it works" weight = 1 +++ ## What is KEDA? **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. ## How KEDA works KEDA performs two key roles within Kubernetes: 1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA. 1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out. It is up to the Deployment to consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box. The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA. ## Architecture The diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store: ![KEDA architecture](/img/keda-arch-no-webhooks.png) ### Event sources and scalers KEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available: {{< scalers-compact >}} ### Custom Resources (CRD) When you install KEDA, it creates four custom resources: 1. `scaledobjects.keda.sh` 1. `scaledjobs.keda.sh` 1. `triggerauthentications.keda.sh` 1. `clustertriggerauthentications.keda.sh` These custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling. - `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. - `ScaledJobs` represent the mapping between event source and Kubernetes Job. - `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source. ## Deploy KEDA See the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm). ================================================ FILE: content/docs/2.9/concepts/authentication.md ================================================ +++ title = "Authentication" weight = 500 +++ Often a scaler will require authentication or secrets and config to check for events. KEDA provides a few secure patterns to manage authentication flows: * Configure authentication per `ScaledObject` * Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication` * Re-use global credentials with `ClusterTriggerAuthentication` ## Defining secrets and config maps on ScaledObject Some metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container. > 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.* ### Example If using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference. You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below: ```yaml apiVersion: v1 kind: Secret metadata: name: {secret-name} data: {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec --- apiVersion: apps/v1 kind: Deployment metadata: name: {deployment-name} namespace: default labels: app: {deployment-name} spec: selector: matchLabels: app: {deployment-name} template: metadata: labels: app: {deployment-name} spec: containers: - name: {deployment-name} image: {container-image} envFrom: - secretRef: name: {secret-name} --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} namespace: default spec: scaleTargetRef: name: {deployment-name} triggers: - type: rabbitmq metadata: queueName: hello host: {secret-key-name} queueLength : '5' ``` If you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`. If you do not include a `envSourceContainerName` it will default to the first container. KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container. ### The downsides While this method works for many scenarios, there are some downsides: * **Difficult to efficiently share auth** config across `ScaledObjects` * **No support for referencing a secret directly**, only secrets that are referenced by the container * **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings For these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team. ## Re-use credentials and delegate auth with TriggerAuthentication `TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers. It also enables more advanced methods of authentication like "pod identity", authentication re-use or allowing IT to configure the authentication. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: {trigger-authentication-name} namespace: default # must be same namespace as the ScaledObject spec: podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. secretTargetRef: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {secret-name} # Required. key: {secret-key-name} # Required. env: # Optional. - parameter: {scaledObject-parameter-name} # Required. name: {env-name} # Required. containerName: {container-name} # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. podIdentity: # Optional. Required when using pod identity. provider: azure | azure-workload # Required. identityId: # Optional credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` Based on the requirements you can mix and match the reference types providers in order to configure all required parameters. Every parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger. ```yaml # some Scaled Object # ... triggers: - type: {scaler-type} metadata: param1: {some-value} authenticationRef: name: {trigger-authentication-name} # this may define other params not defined in metadata ``` ## Authentication scopes: Namespace vs. Cluster Each `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference: ```yaml authenticationRef: name: {cluster-trigger-authentication-name} kind: ClusterTriggerAuthentication ``` By default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container. Defining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value: ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: {cluster-trigger-authentication-name} spec: # As before ... ``` ## Authentication parameters Authentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. ### Environment variable(s) You can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`. ```yaml env: # Optional. - parameter: region # Required - Defined by the scale trigger name: my-env-var # Required. containerName: my-container # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject ``` **Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Secret(s) You can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use. ```yaml secretTargetRef: # Optional. - parameter: connectionString # Required - Defined by the scale trigger name: my-keda-secret-entity # Required. key: azure-storage-connectionstring # Required. ``` **Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise. ### Hashicorp Vault secret(s) You can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well. `credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token. `secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter. `namespace` may be used to target a given Vault Enterprise namespace. ```yaml hashiCorpVault: # Optional. address: {hashicorp-vault-address} # Required. namespace: {hashicorp-vault-namespace} # Optional. Default is root namespace. Useful for Vault Enterprise authentication: token | kubernetes # Required. role: {hashicorp-vault-role} # Optional. mount: {hashicorp-vault-mount} # Optional. credential: # Optional. token: {hashicorp-vault-token} # Optional. serviceAccount: {path-to-service-account-file} # Optional. secrets: # Required. - parameter: {scaledObject-parameter-name} # Required. key: {hashicorp-vault-secret-key-name} # Required. path: {hashicorp-vault-secret-path} # Required. ``` ### Azure Key Vault secret(s) You can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key. The `secrets` list defines the mapping between the key vault secret and the authentication parameter. You can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the `TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace. If you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource. Ensure that "read secret" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal). The `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like `Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds. ```yaml azureKeyVault: # Optional. vaultUri: {key-vault-address} # Required. credentials: # Optional. Required when not using pod identity. clientId: {azure-ad-client-id} # Required. clientSecret: # Required. valueFrom: # Required. secretKeyRef: # Required. name: {k8s-secret-with-azure-ad-secret} # Required. key: {key-within-the-secret} # Required. tenantId: {azure-ad-tenant-id} # Required. cloud: # Optional. type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required. keyVaultResourceURL: {key-vault-resource-url-for-cloud} # Required when type = Private. activeDirectoryEndpoint: {active-directory-endpoint-for-cloud} # Required when type = Private. secrets: # Required. - parameter: {param-name-used-for-auth} # Required. name: {key-vault-secret-name} # Required. version: {key-vault-secret-version} # Optional. ``` ### Pod Authentication Providers Several service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets. Currently we support the following: ```yaml podIdentity: provider: none | azure | azure-workload | aws-eks | aws-kiam # Optional. Default: none identityId: # Optional. Only used by azure & azure-workload providers. ``` #### Azure Pod Identity Azure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure # Optional. Default: none identityId: # Optional. Default: Identity linked with the label set when installing KEDA. ``` Azure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`. You can set this label on the KEDA operator deployment. This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`. You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### Azure Workload Identity [**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an [**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*. You can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`. ```yaml podIdentity: provider: azure-workload # Optional. Default: none identityId: # Optional. Default: ClientId From annotation on service-account. ``` Azure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the following flags - 1. `--set podIdentity.azureWorkload.enabled=true` 2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}` 3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}` You can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. #### AWS EKS Pod Identity Webhook [**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod. You can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`. ```yaml podIdentity: provider: aws-eks # Optional. Default: none ``` #### AWS Kiam Pod Identity [**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod. You can tell KEDA to use Kiam via `podIdentity.provider`. ```yaml podIdentity: provider: aws-kiam # Optional. Default: none ``` ================================================ FILE: content/docs/2.9/concepts/external-scalers.md ================================================ +++ title = "External Scalers" weight = 500 +++ While KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers. Built-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones. This document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/) > Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers). ## Overview ### Built-in scalers interface Since external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement: ```go // Scaler interface type Scaler interface { // GetMetricsAndActivity returns the metric values and activity for a metric Name GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) // GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for // this scaled object. The labels used should match the selectors used in GetMetrics GetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec // Close any resources that need disposing when scaler is no longer used or destroyed Close(ctx context.Context) error } // PushScaler interface type PushScaler interface { Scaler // Run is the only writer to the active channel and must close it once done. Run(ctx context.Context, active chan<- bool) } ``` The `Scaler` interface defines 3 methods: - `Close` is called to allow the scaler to clean up connections or other resources. - `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec). - `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob. When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec). > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas. The `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`. ### External Scaler GRPC interface KEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md). The configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract: ```proto service ExternalScaler { rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {} rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {} rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {} rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {} } ``` Much of this contract is similar to the built-in scalers: - `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition. - `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface. - `StreamIsActive` maps to the `Run` method on the `PushScaler` interface. There are, however, some notable differences: - There is no `Close` method. The scaler is expected to be functional throughout its lifetime. - `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger. ### Example Given the following `ScaledObject`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external-push metadata: scalerAddress: service-address.svc.local:9090 key1: value1 key2: value2 ``` KEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls: - `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval` - `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect - `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter: - `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`. ```json { "name": "scaledobject-name", "namespace": "scaledobject-namespace", "scalerMetadata": { "scalerAddress": "service-address.svc.local:9090", "key1": "value1", "key2": "value2" } } ``` > **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called. ## Implementing KEDA external scaler GRPC interface ### Implementing an external scaler #### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) #### 2. Prepare project {{< collapsible "Golang" >}} 2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform 2.2. get `protoc-gen-go` ```bash go get github.com/golang/protobuf/protoc-gen-go@v1.3.2 ``` 2.3. Prepare project ```bash go mod init example.com/external-scaler/sample mkdir externalscaler protoc externalscaler.proto --go_out=plugins=grpc:externalscaler ``` {{< /collapsible >}} {{< collapsible "C#" >}} 2.1. Create a new project ```bash dotnet new console -o ExternalScalerSample cd ExternalScalerSample # add Grpc.AspNetCore dotnet add package Grpc.AspNetCore dotnet add package Newtonsoft.Json # Create a Protos and Services folders mkdir Protos mkdir Services ``` 2.2. Move `externalscaler.proto` to `Protos` folder 2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj` ```xml ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} 2.1. Prepare the project ```bash npm install --save grpc request ``` {{< /collapsible >}} #### 3. Implementing `IsActive` Just like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day. Submit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary): ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: scaledobject-name namespace: scaledobject-namespace spec: scaleTargetRef: name: deployment-name triggers: - type: external metadata: scalerAddress: earthquake-scaler:9090 longitude: "-122.335167" latitude: "47.608013" ``` {{< collapsible "Golang" >}} The full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `main.go` file: ```golang func (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } startTime := time.Now().AddDate(0, 0, -1).Format("2006-01-02") endTime := time.Now().Format("2006-01-02") radiusKM := 500 query := fmt.Sprintf("format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d", startTime, endTime, longitude, latitude, radiusKM) resp, err := http.Get(fmt.Sprintf("https://earthquake.usgs.gov/fdsnws/event/1/query?%s", query)) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } defer resp.Body.Close() body, err := ioutil.ReadAll(resp.Body) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } payload := USGSResponse{} err = json.Unmarshal(body, &payload) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } // count how many earthquakes with mag > 1.0 count := 0 for _, f := range payload.Features { if f.Properties.Mag > 1.0 { count++ } } // return true if there is more than 2 return &pb.IsActiveResponse{ Result: count > 2, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} Full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples). Put the following code into your `Services/ExternalScalerService.cs` file: ```csharp public class ExternalScalerService : ExternalScaler.ExternalScalerBase { private static readonly HttpClient _client = new HttpClient(); public override async Task IsActive(ScaledObjectRef request, ServerCallContext context) { // request.Scalermetadata contains the `metadata` defined in the ScaledObject if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var startTime = DateTime.UtcNow.AddDays(-1).ToString("yyyy-MM-dd"); var endTime = DateTime.UtcNow.ToString("yyyy-MM-dd"); var radiusKm = 500; var query = $"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}"; var resp = await _client.GetAsync($"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}"); resp.EnsureSuccessStatusCode(); var payload = JsonConvert.DeserializeObject(await resp.Content.ReadAsStringAsync()); return new IsActiveResponse { // return true if there is more than 2 Earthquakes with mag > 1.0 Result = payload.features.Count(f => f.properties.mag > 1.0) > 2 }; } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} Put the following code into your `index.js` file: ```js const grpc = require("grpc"); const request = require("request"); const externalScalerProto = grpc.load("externalscaler.proto"); const server = new grpc.Server(); server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { isActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const now = new Date(); const yesterday = new Date(new Date().setDate(new Date().getDate() - 1)); const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`; const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`; const radiusKm = 500; const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`; request.get( { url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`, json: true, }, (err, resp, data) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else if (resp.statusCode !== 200) { callback({ code: grpc.status.INTERNAL, details: `expected status 200, got ${resp.statusCode}`, }); } else { // count how many earthquakes with mag > 1.0 let count = 0; data.features.forEach((i) => { if (i.properties.mag > 1.0) { count++; } }); callback(null, { result: count > 2, }); } } ); } }, }); server.bind("127.0.0.1:9090", grpc.ServerCredentials.createInsecure()); console.log("Server listening on 127.0.0.1:9090"); server.start(); ``` {{< /collapsible >}} #### 4. Implementing `StreamIsActive` Unlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment. This implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error { longitude := scaledObject.ScalerMetadata["longitude"] latitude := scaledObject.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } for { select { case <-epsServer.Context().Done(): // call cancelled return nil case <-time.Tick(time.Hour * 1): earthquakeCount, err := getEarthQuakeCount(longitude, latitude) if err != nil { // log error } else if earthquakeCount > 2 { err = epsServer.Send(&pb.IsActiveResponse{ Result: true, }) } } } } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter responseStream, ServerCallContext context) { if (!request.ScalerMetadata.ContainsKey("latitude") || !request.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScalerMetadata["longitude"]; var latitude = request.ScalerMetadata["latitude"]; var key = $"{longitude}|{latitude}"; while (!context.CancellationToken.IsCancellationRequested) { var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); if (earthquakeCount > 2) { await responseStream.WriteAsync(new IsActiveResponse { Result = true }); } await Task.Delay(TimeSpan.FromHours(1)); } } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... streamIsActive: (call, callback) => { const longitude = call.request.scalerMetadata.longitude; const latitude = call.request.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { const interval = setInterval(() => { getEarthquakeCount((err, count) => { if (err) { console.error(err); } else if (count > 2) { call.write({ result: true, }); } }); }, 1000 * 60 * 60); call.on("end", () => { clearInterval(interval); }); } }, }); ``` {{< /collapsible >}} #### 5. Implementing `GetMetricSpec` `GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) { return &pb.GetMetricSpecResponse{ MetricSpecs: []*pb.MetricSpec{{ MetricName: "earthquakeThreshold", TargetSize: 10, }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetricSpec(ScaledObjectRef request, ServerCallContext context) { var resp = new GetMetricSpecResponse(); resp.MetricSpecs.Add(new MetricSpec { MetricName = "earthquakeThreshold", TargetSize = 10 }); return Task.FromResult(resp); } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetricSpec: (call, callback) => { callback(null, { metricSpecs: [ { metricName: "earthquakeThreshold", targetSize: 10, }, ], }); }, }); ``` {{< /collapsible >}} #### 6. Implementing `GetMetrics` `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`. {{< collapsible "Golang" >}} ```golang func (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) { longitude := metricRequest.ScaledObjectRef.ScalerMetadata["longitude"] latitude := metricRequest.ScaledObjectRef.ScalerMetadata["latitude"] if len(longitude) == 0 || len(latitude) == 0 { return nil, status.Error(codes.InvalidArgument, "longitude and latitude must be specified") } earthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0) if err != nil { return nil, status.Error(codes.Internal, err.Error()) } return &pb.GetMetricsResponse{ MetricValues: []*pb.MetricValue{{ MetricName: "earthquakeThreshold", MetricValue: int64(earthquakeCount), }}, }, nil } ``` {{< /collapsible >}} {{< collapsible "C#" >}} ```csharp public override async Task GetMetrics(GetMetricsRequest request, ServerCallContext context) { if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey("latitude") || !request.ScaledObjectRef.ScalerMetadata.ContainsKey("longitude")) { throw new ArgumentException("longitude and latitude must be specified"); } var longitude = request.ScaledObjectRef.ScalerMetadata["longitude"]; var latitude = request.ScaledObjectRef.ScalerMetadata["latitude"]; var earthquakeCount = await GetEarthQuakeCount(longitude, latitude); var resp = new GetMetricsResponse(); resp.MetricValues.Add(new MetricValue { MetricName = "earthquakeThreshold", MetricValue_ = earthquakeCount }); return resp; } ``` {{< /collapsible >}} {{< collapsible "Javascript" >}} ```js server.addService(externalScalerProto.externalscaler.ExternalScaler.service, { // ... getMetrics: (call, callback) => { const longitude = call.request.scaledObjectRef.scalerMetadata.longitude; const latitude = call.request.scaledObjectRef.scalerMetadata.latitude; if (!longitude || !latitude) { callback({ code: grpc.status.INVALID_ARGUMENT, details: "longitude and latitude must be specified", }); } else { getEarthquakeCount((err, count) => { if (err) { callback({ code: grpc.status.INTERNAL, details: err, }); } else { callback(null, { metricValues: [ { metricName: "earthquakeThreshold", metricValue: count, }, ], }); } }); } }, }); ``` {{< /collapsible >}} ================================================ FILE: content/docs/2.9/concepts/scaling-deployments.md ================================================ +++ title = "Scaling Deployments, StatefulSets & Custom Resources" weight = 200 +++ ## Overview ### Scaling of Deployments and StatefulSets Deployments and StatefulSets are the most common way to scale workloads with KEDA. It allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly. Behind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource. Each replica of a resource is actively pulling items from the event source. With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing). For example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be: * When no messages are pending processing, KEDA can scale the deployment to zero. * When a message arrives, KEDA detects this event and activates the deployment. * When the deployment starts running, one of the containers connects to Kafka and starts pulling messages. * As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out. * Each replica of the deployment is actively processing messages. Very likely, each replica is processing a batch of messages in a distributed manner. ### Scaling of Custom Resources With KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`. The only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource). ## ScaledObject spec This specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. [`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: {scaled-object-name} spec: scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] pollingInterval: 30 # Optional. Default: 30 seconds cooldownPeriod: 300 # Optional. Default: 300 seconds idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount minReplicaCount: 1 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included advanced: # Optional. Section to specify advanced options restoreToOriginalReplicaCount: true/false # Optional. Default: false horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 triggers: # {list of triggers to activate scaling of the target resource} ``` ### Details ```yaml scaleTargetRef: apiVersion: {api-version-of-target-resource} # Optional. Default: apps/v1 kind: {kind-of-target-resource} # Optional. Default: Deployment name: {name-of-target-resource} # Mandatory. Must be in the same namespace as the ScaledObject envSourceContainerName: {container-name} # Optional. Default: .spec.template.spec.containers[0] ``` The reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`. To scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified. `envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc. If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`. **Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject --- #### pollingInterval ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds. **Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly. --- #### cooldownPeriod ```yaml cooldownPeriod: 300 # Optional. Default: 300 seconds ``` The period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds). The `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`. Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). **Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`) --- #### idleReplicaCount ```yaml idleReplicaCount: 0 # Optional. Default: ignored, must be less than minReplicaCount ``` > 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details. > > In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`. > > **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1). If this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`. **Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0). --- #### minReplicaCount ```yaml minReplicaCount: 1 # Optional. Default: 0 ``` Minimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. --- #### maxReplicaCount ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` This setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource. --- #### fallback ```yaml fallback: # Optional. Section to specify fallback options failureThreshold: 3 # Mandatory if fallback section is included replicas: 6 # Mandatory if fallback section is included ``` The `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state. KEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula: ``` target metric value * fallback replicas ``` Due to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas. **Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas. There are a few limitations to using a fallback: - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled. - It is only supported by `ScaledObjects` **not** `ScaledJobs`. --- #### advanced ```yaml advanced: restoreToOriginalReplicaCount: true/false # Optional. Default: false ``` This property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. Default behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion. For example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted: 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10` 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value) --- ```yaml advanced: horizontalPodAutoscalerConfig: # Optional. Section to specify HPA related options name: {name-of-hpa-resource} # Optional. Default: keda-hpa-{scaled-object-name} behavior: # Optional. Use to modify HPA's scaling behavior scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 100 periodSeconds: 15 ``` ##### `horizontalPodAutoscalerConfig` ###### `horizontalPodAutoscalerConfig.name` The name of the HPA resource KEDA will create. By default it's `keda-hpa-{scaled-object-name}` ###### `horizontalPodAutoscalerConfig.behavior` Starting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details. **Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting. --- #### triggers ```yaml triggers: # {list of triggers to activate scaling of the target resource} ``` > 💡 **NOTE:** You can find all supported triggers [here](/scalers). Trigger fields: - **type**: The type of trigger to use. (Mandatory) - **metadata**: The configuration parameters that the trigger requires. (Mandatory) - **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default the name is generated from the trigger type. (Optional) - **useCachedMetrics**: ([Experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features)) Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see ["Caching Metrics (Experimental)"](#caching-metrics-experimental). (Values: `false`, `true`, Default: `false`, Optional) - **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment. - More details can be found [here](./authentication). (Optional) - **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional) - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value. - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages: - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count. - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12. > ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`. ### Caching Metrics (Experimental) This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. Enabling this feature can significantly reduce the load on the scaler service. This is an [experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features). This feature is not supported for `cpu`, `memory` or `cron` scaler. ### Pause autoscaling It can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition: ```yaml metadata: annotations: autoscaling.keda.sh/paused-replicas: "0" ``` The presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition. ### Activating and Scaling thresholds To give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process. - **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X. - **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling. #### Managing Activation & Scaling Thresholds KEDA allows you to specify different values for each scenario: - **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it. - **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling. > ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored. Each scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation). There are some important topics to take into account: - Opposite to scaling value, the activation value is always optional and the default value is 0. - Activation only occurs when this value is greater than the set value; not greater than or equal to. - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more - The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances. > ⚠️ **NOTE:** If a scaler doesn't define "activation" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0. ## Long-running executions One important consideration to make is how this pattern can work with long-running executions. Imagine a deployment triggers on a RabbitMQ queue message. Each message takes 3 hours to process. It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4. Now the HPA makes a decision to scale down from 4 replicas to 2. There is no way to control which of the 2 replicas get terminated to scale down. That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message. There are two main ways to handle this scenario. ### Leverage the container lifecycle Kubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination. Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message. Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate. Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed. Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica. > 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks). Using this method can preserve a replica and enable long-running executions. However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state. That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay. ### Run as jobs The other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources. This approach is discussed [in the next section](../scaling-jobs). ================================================ FILE: content/docs/2.9/concepts/scaling-jobs.md ================================================ +++ title = "Scaling Jobs" weight = 300 +++ ## Overview As an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs. The primary reason to consider this option is to handle processing long-running executions. Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled. That job will initialize, pull a single event from the message source, and process to completion and terminate. For example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be: 1. When no messages are awaiting processing, no jobs are created. 1. When a message arrives at the queue, KEDA creates a job. 1. When the job starts running, it pulls *a single* message and processes it to completion. 1. As additional messages arrive, additional jobs are created. Each job processes a single message to completion. 1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.` ## ScaledJob spec This specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are. [`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: {scaled-job-name} spec: jobTargetRef: parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism) activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6 template: # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job) pollingInterval: 30 # Optional. Default: 30 seconds successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] minReplicaCount: 10 # Optional. Default: 0 maxReplicaCount: 100 # Optional. Default: 100 rolloutStrategy: gradual # Deprecated: Use rollout.strategy instead (see below). rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. pendingPodConditions: # Optional. A parameter to calculate pending job count per the specified pod conditions - "Ready" - "PodScheduled" - "AnyOtherCustomPodCondition" multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined. triggers: # {list of triggers to create jobs} ``` You can find all supported triggers [here](../scalers). ## Details ```yaml jobTargetRef: parallelism: 1 # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) completions: 1 # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)) activeDeadlineSeconds: 600 # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer backoffLimit: 6 # Optional. Specifies the number of retries before marking this job failed. Defaults to 6 ``` The `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required. --- ```yaml pollingInterval: 30 # Optional. Default: 30 seconds ``` This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds. --- ```yaml successfulJobsHistoryLimit: 5 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 5 # Optional. Default: 100. How many failed jobs should be kept. ``` The `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100. This concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are. The actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval. --- ```yaml envSourceContainerName: {container-name} # Optional. Default: .spec.JobTargetRef.template.spec.containers[0] ``` This optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`. ___ ```yaml minReplicaCount: 10 # Optional. Default: 0 ``` The min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount. New messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running. For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2. ___ --- ```yaml maxReplicaCount: 100 # Optional. Default: 100 ``` The max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic. | Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale | | ------- | ------ | ------- | ------ | ----- | | 10 | 3 | 1 | 0 | 3 | | 10 | 3 | 2 | 0 | 3 | | 10 | 3 | 1 | 1 | 2 | | 10 | 100 | 1 | 0 | 10 | | 4 | 3 | 5 | 0 | 1 | * **Queue Length:** The number of items in the queue. * **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler. * **Running Job Count:** How many jobs are running. * **Number of the Scale:** The number of the job that is created. --- ```yaml rollout: strategy: gradual # Optional. Default: default. Which Rollout Strategy KEDA will use. propagationPolicy: foreground # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during ``` The optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob. Possible values are `default` or `gradual`. \ When using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). On the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. --- ```yaml scalingStrategy: strategy: "default" # Optional. Default: default. Which Scaling Strategy to use. ``` Select a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`. > 💡 **NOTE:** > >`maxScale` is not the running Job count. It is measured as follows: >```go >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue)) >``` >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`. > >`RunningJobCount` represents the number of jobs that are currently running or have not finished yet. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > runningJobs++ >} >``` >`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways: > - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet > - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes. > >It is measured as follows: >```go >if !e.isJobFinished(&job) { > if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 { > if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) { > pendingJobs++ > } > } else { > if !e.isAnyPodRunningOrCompleted(&job) { > pendingJobs++ > } > } >} >``` **default** This logic is the same as Job for V1. The number of the scale will be calculated as follows. _The number of the scale_ ```go maxScale - runningJobCount ``` **custom** You can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.` ```yaml customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. ``` _The number of the scale_ ```go min(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount) ``` **accurate** If the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it. ```go if (maxScale + runningJobCount) > maxReplicaCount { return maxReplicaCount - runningJobCount } return maxScale - pendingJobCount ``` For more details, you can refer to [this PR](https://github.com/kedacore/keda/pull/1227). --- ```yaml scalingStrategy: multipleScalersCalculation : "max" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined. ``` Select a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. * **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default) * **min:** - Use metrics from the scaler that has the min number of `queueLength`. * **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers. * **sum:** - Sum up all the active scalers metrics. # Sample ```yaml apiVersion: v1 kind: Secret metadata: name: rabbitmq-consumer data: RabbitMqHost: --- apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: rabbitmq-consumer namespace: default spec: jobTargetRef: template: spec: containers: - name: demo-rabbitmq-client image: demo-rabbitmq-client:1 imagePullPolicy: Always command: ["receive", "amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672"] envFrom: - secretRef: name: rabbitmq-consumer-secrets restartPolicy: Never backoffLimit: 4 pollingInterval: 10 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 3 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 2 # Optional. Default: 100. How many failed jobs should be kept. scalingStrategy: strategy: "custom" # Optional. Default: default. Which Scaling Strategy to use. customScalingQueueLengthDeduction: 1 # Optional. A parameter to optimize custom ScalingStrategy. customScalingRunningJobPercentage: "0.5" # Optional. A parameter to optimize custom ScalingStrategy. triggers: - type: rabbitmq metadata: queueName: hello host: RabbitMqHost queueLength : '5' ``` ================================================ FILE: content/docs/2.9/concepts/troubleshooting.md ================================================ +++ title = "Troubleshooting" weight = 600 +++ ## KEDA logging and telemetry The first place to look if something isn't behaving correctly is the logs generated from KEDA. After deploying you should have a pod with two containers running within the namespace (by default: `keda`). You can view the KEDA operator pod via kubectl: ```sh kubectl get pods -n keda ``` You can view the logs for the keda operator container with the following: ```sh kubectl logs -n keda {keda-pod-name} -c keda-operator ``` ## Reporting issues If you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior. ================================================ FILE: content/docs/2.9/deploy.md ================================================ +++ title = "Deploying KEDA" +++ We provide a few approaches to deploy KEDA runtime in your Kubernetes clusters: - [Helm charts](#helm) - [Operator Hub](#operatorhub) - [YAML declarations](#yaml) > 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.23 and higher Don't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo. ## Deploying with Helm {#helm} ### Install Deploying KEDA with Helm is very simple: 1. Add Helm repo ```sh helm repo add kedacore https://kedacore.github.io/charts ``` 2. Update Helm repo ```sh helm repo update ``` 3. Install `keda` Helm chart **Helm 3** ```sh helm install keda kedacore/keda --namespace keda --create-namespace ``` > 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues. ### Uninstall If you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled: ```sh kubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}') helm uninstall keda -n keda ``` Note: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed: ```sh for i in $(kubectl get scaledobjects -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done for i in $(kubectl get scaledjobs -A \ -o jsonpath='{"-n "}{.items[*].metadata.namespace}{" "}{.items[*].kind}{"/"}{.items[*].metadata.name}{"\n"}'); do kubectl patch $i -p '{"metadata":{"finalizers":null}}' --type=merge done ``` ## Deploying with Operator Hub {#operatorhub} ### Install 1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda` 2. Create `KedaController` resource named `keda` in namespace `keda` ![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif) > 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator). ### Uninstall Locate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator. ## Deploying using the deployment YAML files {#yaml} ### Install If you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`. - We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. Run the following command (if needed, replace the version, in this case `2.9.3`, with the one you are using): ```sh kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.9.3/keda-2.9.3.yaml ``` - Alternatively you can download the file and deploy it from the local path: ```sh kubectl apply -f keda-2.9.3.yaml ``` - You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it. ```sh git clone https://github.com/kedacore/keda && cd keda VERSION=2.9.3 make deploy ``` ### Uninstall - In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.9.3`, with the one you are using): ```sh kubectl delete -f https://github.com/kedacore/keda/releases/download/v2.9.3/keda-2.9.3.yaml ``` - If you have downloaded the file locally, you can run: ```sh kubectl delete -f keda-2.9.3.yaml ``` - You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda): ```sh VERSION=2.9.3 make undeploy ``` ## Deploying KEDA on MicroK8s {#microk8s} ### Install If you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons. ```sh microk8s enable keda ``` ### Uninstall To uninstall KEDA in MicroK8s, simply disable the addon as shown below. ```sh microk8s disable keda ``` ================================================ FILE: content/docs/2.9/integrations/_index.md ================================================ +++ title = "Integrations" weight = 6 +++ An overview of tools/products integrating with KEDA: {{< integrations >}} ================================================ FILE: content/docs/2.9/integrations/prometheus.md ================================================ +++ title = "Integrate with Prometheus" description = "Overview of all Prometheus metrics that KEDA provides" availability = "v2.0+" project = "Prometheus" +++ ## Prometheus Exporter Metrics ### Operator The KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered: - `keda_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. - `keda_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_scaled_object_errors`- The number of errors that have occurred for each ScaledObject. - `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). - `keda_trigger_totals` - Total number of triggers per trigger type. - Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics). ### Metrics Server > 💡 **DEPRECATED:** Prometheus Metrics exposed from Metrics Server are deprecated, please consume metrics from KEDA Operator. The KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas). The following metrics are being gathered: - `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers. - `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object. - `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler. - `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average. ## Premade Grafana dashboard A premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter. ![KEDA Grafana dashboard](/img/grafana-dashboard.png) The dashboard has two sections: - Visualization of KEDA's metric server - Visualization of the scale target and its changes in replicas scaled by KEDA On top, the dashboard supports the following variables: - datasource - namespace - scaledObject - scaler - metric ================================================ FILE: content/docs/2.9/migration.md ================================================ +++ title = "Migration Guide" +++ ## Migrating from KEDA v1 to v2 Please note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2. > 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well. KEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd). Here's an overview of what's changed: - [Scaling of Deployments](#scaling-of-deployments) - [Scaling of Jobs](#scaling-of-jobs) - [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata) - [Scalers](#scalers) - [TriggerAuthentication](#triggerauthentication) ### Scaling of Deployments In order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name` - Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName` - Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1) Please see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec) **Example of v1 ScaledObject** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } labels: deploymentName: { deployment-name } spec: scaleTargetRef: deploymentName: { deployment-name } containerName: { container-name } pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` **Example of v2 ScaledObject** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledObject metadata: # <--- labels.deploymentName is not needed name: { scaled-object-name } spec: scaleTargetRef: name: { deployment-name } # <--- Property name was changed envSourceContainerName: { container-name } # <--- Property name was changed pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to activate the deployment} ``` ### Scaling of Jobs In order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` - Change the value of `kind` property from `ScaledObject` to `ScaledJob` - Remove property `spec.scaleType` - Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount` You can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically. Please see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec) **Example of v1 ScaledObject for Jobs scaling** ```yaml apiVersion: keda.k8s.io/v1alpha1 kind: ScaledObject metadata: name: { scaled-object-name } spec: scaleType: job jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 cooldownPeriod: 300 minReplicaCount: 0 maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` **Example of v2 ScaledJob** ```yaml apiVersion: keda.sh/v1alpha1 # <--- Property value was changed kind: ScaledJob # <--- Property value was changed metadata: name: { scaled-job-name } spec: # <--- spec.scaleType is not needed jobTargetRef: parallelism: 1 completions: 1 activeDeadlineSeconds: 600 backoffLimit: 6 template: # {job template} pollingInterval: 30 # <--- spec.cooldownPeriod and spec.minReplicaCount are not needed successfulJobsHistoryLimit: 5 # <--- property is added failedJobsHistoryLimit: 5 # <--- Property is added maxReplicaCount: 100 triggers: # {list of triggers to create jobs} ``` ### Improved flexibility & usability of trigger metadata We've introduced more options to configure trigger metadata to give users more flexibility. > 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication` Here's an overview: | Scaler | 1.x | 2.0 | | -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- | | `azure-blob` | `connection` (**Default**: `AzureWebJobsStorage`) | `connectionFromEnv` | | `azure-monitor` | `activeDirectoryClientId` `activeDirectoryClientPassword` | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` | | `azure-queue` | `connection` (**Default**: AzureWebJobsStorage) | `connectionFromEnv` | | `azure-servicebus` | `connection` | `connectionFromEnv` | | `azure-eventhub` | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`) | `storageConnectionFromEnv` `connectionFromEnv` | | `aws-cloudwatch` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `aws-sqs-queue` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv` | | `kafka` | _(none)_ | _(none)_ | | `rabbitmq` | `apiHost` `host` | ~~`apiHost`~~ `host` `hostFromEnv` | | `prometheus` | _(none)_ | _(none)_ | | `cron` | _(none)_ | _(none)_ | | `redis` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `redis-streams` | `address` `host` `port` `password` | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv` | | `gcp-pubsub` | `credentials` | `credentialsFromEnv` | | `external` | _(any matching value)_ | _(any matching value with `FromEnv` suffix)_ | | `liiklus` | _(none)_ | _(none)_ | | `stan` | _(none)_ | _(none)_ | | `huawei-cloudeye` | | _(none)_ | _(none)_ | | `postgresql` | `connection` `password` | `connectionFromEnv` `passwordFromEnv` | | `mysql` | `connectionString` `password` | `connectionStringFromEnv` `passwordFromEnv` | ### Scalers **Azure Service Bus** - `queueLength` was renamed to `messageCount` **Kafka** - `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details. **RabbitMQ** In KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by `protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP protocol. Example of RabbitMQ trigger before 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue includeUnacked: "true" apiHost: "https://guest:password@localhost:443/vhostname" ``` The same trigger in 2.0: ```yaml triggers: - type: rabbitmq metadata: queueLength: "20" queueName: testqueue protocol: "http" host: "https://guest:password@localhost:443/vhostname" ``` ### TriggerAuthentication In order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change: - Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1` For more details please refer to the full [v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication) ================================================ FILE: content/docs/2.9/operate/_index.md ================================================ +++ title = "Operate" description = "Guidance & requirements for operating KEDA" weight = 1 +++ We provide guidance & requirements around various areas to operate KEDA: - [Cluster](./cluster) - [Kubernetes Events](./events) - [KEDA Metrics Server](./metrics-server) ================================================ FILE: content/docs/2.9/operate/cluster.md ================================================ +++ title = "Cluster" description = "Guidance & requirements for running KEDA in your cluster" weight = 100 +++ ## Requirements ### Kubernetes Compatibility KEDA is community-supported. For all support options, see the [Support](/support/) page. The tested window of Kubernetes versions with KEDA follows an "N-2" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum. However, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee. As a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version: | KEDA | Kubernetes | | ---- | ------------- | | v2.9 | v1.23 - v1.25 | | v2.8 | v1.17 - v1.25 | | v2.7 | v1.17 - v1.25 | ### Cluster Capacity The KEDA runtime require the following resources in a production-ready setup: | Deployment | CPU | Memory | | -------------- | ----------------------- | ----------------------------- | | Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi | | Operator | Limit: 1, Request: 100m | Limit: 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) 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: | Port | Why? | Remarks | | ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | `443` | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane → port 443 on the Service IP range communication. This is not applicable for Google Cloud. | | `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane → port 6443 on the Pod IP range for communication | ## 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: | Deployment | Support Replicas | Note | | -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Metrics Server | 1 | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. | | Operator | 2 | While you can run multiple 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 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: ```yaml - 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. ```yaml - 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: | Adapter Flag | Client Config Setting | Default Value | Description | | ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | kube-api-qps | cfg.QPS | 20.0 | Set the QPS rate for throttling requests sent to the apiserver | | kube-api-burst | cfg.Burst | 30 | Set the burst for throttling requests sent to the apiserver | | disable-compression | cfg.DisableCompression | true | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details | ## Configure `MaxConcurrentReconciles` for Controllers To implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), 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 name | Deployment | Default Value | Affected reconciler | | ------------------------------------- | -------------- | ------------- | ----------------------------- | | KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator | 5 | ScaledObjectReconciler | | KEDA_SCALEDJOB_CTRL_MAX_RECONCILES | Operator | 1 | ScaledJobReconciler | | KEDA_METRICS_CTRL_MAX_RECONCILES | Metrics Server | 1 | MetricsScaledObjectReconciler | ## Configure Leader Election Like reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment: - [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration) - [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline) - [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod) To specify values other than their defaults, you can set the following environment variables: | Environment variable name | Deployment | Default Value | Manager Property | | -------------------------------------------- | -------------- | ------------- | ---------------- | | KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator | 15s | LeaseDuration | | KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator | 10s | RenewDeadline | | KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD | Operator | 2s | RetryPeriod | | KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION | Metrics Server | 15s | LeaseDuration | | KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE | Metrics Server | 10s | RenewDeadline | | KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD | Metrics Server | 2s | RetryPeriod | ## 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: ```yaml --- 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](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA). You should also make sure that `insecureSkipTLSVerify` is not set to `true`. ```yaml --- 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: ```yaml - 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: ```yaml 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`. ================================================ FILE: content/docs/2.9/operate/events.md ================================================ +++ title = "Events" description = "Kubernetes Events emitted by KEDA" weight = 100 +++ ## Kubernetes Events emitted by KEDA KEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core): | Event | Type | Description | | ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- | | `ScaledObjectReady` | `Normal` | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledJobReady` | `Normal` | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` | | `ScaledObjectCheckFailed` | `Warning` | If the check validation for a ScaledObject fails | | `ScaledJobCheckFailed` | `Warning` | If the check validation for a ScaledJob fails | | `ScaledObjectDeleted` | `Normal` | When a ScaledObject is deleted and removed from KEDA watch | | `ScaledJobDeleted` | `Normal` | When a ScaledJob is deleted and removed from KEDA watch | | `KEDAScalersStarted` | `Normal` | When Scalers watch loop have started for a ScaledObject or ScaledJob | | `KEDAScalersStopped` | `Normal` | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob | | `KEDAScalerFailed` | `Warning` | When a Scaler fails to create or check its event source | | `KEDAScaleTargetActivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1 | | `KEDAScaleTargetDeactivated` | `Normal` | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 | | `KEDAScaleTargetActivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1 | | `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0 | | `KEDAJobsCreated` | `Normal` | When KEDA creates jobs for a ScaledJob | | `TriggerAuthenticationAdded` | `Normal` | When a new TriggerAuthentication is added | | `TriggerAuthenticationDeleted` | `Normal` | When a TriggerAuthentication is deleted | | `ClusterTriggerAuthenticationAdded` | `Normal` | When a new ClusterTriggerAuthentication is added | | `ClusterTriggerAuthenticationDeleted` | `Normal` | When a ClusterTriggerAuthentication is deleted | ================================================ FILE: content/docs/2.9/operate/metrics-server.md ================================================ +++ title = "KEDA Metrics Server" description = "Details on KEDA Metrics Server" weight = 100 +++ ## Querying metrics exposed by KEDA Metrics Server The metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" ``` This will return a json with the list of metrics exposed by KEDA: ```json { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "external.metrics.k8s.io/v1beta1", "resources": [ { "name": "s0-rabbitmq-queueName", "singularName": "", "namespaced": true, "kind": "ExternalMetricValueList", "verbs": [ "get" ] }, { "name": "s1-rabbitmq-queueName2", .... } ] } ``` You can also query for the value of a specific metric using `kubectl`: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}" ``` At this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside. For example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this: ```bash kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object" ``` And it will show a json like this: ```json { "kind": "ExternalMetricValueList", "apiVersion": "external.metrics.k8s.io/v1beta1", "metadata": {}, "items": [ { "metricName": "s1-rabbitmq-queueName2", "metricLabels": null, "timestamp": "2021-10-20T10:48:17Z", "value": "0" } ] } ``` > **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`. ## How to get metric names from ScaledObject During its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject. You can recover the metric names from a ScaledObject using `kubectl`: ```bash kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames} ``` ================================================ FILE: content/docs/2.9/reference/faq.md ================================================ +++ title = "FAQ" +++ {{< faq20 versionData="faq20" >}} ================================================ FILE: content/docs/2.9/scalers/_index.md ================================================ +++ title = "Scalers" weight = 2 +++ KEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. ================================================ FILE: content/docs/2.9/scalers/activemq.md ================================================ +++ title = "ActiveMQ" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on ActiveMQ Queue." go_file = "activemq_scaler" +++ ### Trigger Specification This specification describes the `activemq` trigger that scales based on a ActiveMQ Queue. ```yaml triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQueue" brokerName: "activemq_broker" targetQueueSize: "100" activationTargetQueueSize: "10" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ management endpoint in format: `:`. - `destinationName` - Name of the queue to check for the message count. - `brokerName` - Name of the broker as defined in ActiveMQ. - `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional) - `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restAPITemplate` - Template to build REST API url to get queue size. (Default: `"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) **Parameter Requirements:** - In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`. - ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below. ### Authentication Parameters You can authenticate by using username and password via `TriggerAuthentication` configuration. **Username and Password based Authentication:** - `username` - Username for connect to the management endpoint of ActiveMQ. - `password` - Password for connect to the management endpoint of ActiveMQ. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: activemq-secret type: Opaque data: activemq-password: ACTIVEMQ_PASSWORD activemq-username: ACTIVEMQ_USERNAME --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-activemq spec: secretTargetRef: - parameter: username name: activemq-secret key: activemq-username - parameter: password name: activemq-secret key: activemq-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: activemq-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: activemq metadata: managementEndpoint: "activemq.activemq-test:8161" destinationName: "testQ" brokerName: "localhost" targetQueueSize: "50" authenticationRef: name: trigger-auth-activemq ``` ================================================ FILE: content/docs/2.9/scalers/apache-kafka.md ================================================ +++ title = "Apache Kafka" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an Apache Kafka topic or other services that support Kafka protocol." go_file = "kafka_scaler" +++ > **Notice:** > - By default, the number of replicas will not exceed: > - The number of partitions on a topic when a topic is specified; > - The number of partitions of *all topics* in the consumer group when no topic is specified; > - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account; > > That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior. > - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle. ### Trigger Specification This specification describes the `kafka` trigger for an Apache Kafka topic. ```yaml triggers: - type: kafka metadata: bootstrapServers: kafka.svc:9092 consumerGroup: my-group topic: test-topic lagThreshold: '5' activationLagThreshold: '3' offsetResetPolicy: latest allowIdleConsumers: 'false' scaleToZeroOnInvalidOffset: 'false' excludePersistentLag: 'false' version: 1.0.0 partitionLimitation: '1,2,10-20,31' ``` **Parameter list:** - `bootstrapServers` - Comma separated list of Kafka brokers "hostname:port" to connect to for bootstrap. - `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag. - `topic` - Name of the topic on which processing the offset lag. (Optional, see note below) - `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional) - `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: `false`, Optional) - `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset. If 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that partition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter. - `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional) - `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional) - `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are "x,y" and/or ranges "x-y". If set, the calculation of the lag will only take these ids into account. (Default: All partitions, Optional) > **Note:** > > When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group. > - When there are **active** consumer instances, _all topics_ includes: > - Topics the consumer is *currently* subscribing to; > - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days)); > - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*; > --- > An edge case exists where scaling could be **effectively disabled**: > - Consumer never makes a commit (no record in `__consumer_offset`); > - and `ScaledObject` had `minReplicaCount` as 0; > > In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered. > > Fix for such case: > - Set `minReplicaCount` > 0; > - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected; ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **SASL:** - `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional) - `username` - Username used for sasl authentication. (Optional) - `password` - Password used for sasl authentication. (Optional) - `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbreaker token requests. (Optional unless sasl mode set to oauthbearer) - `scopes` - A comma separated lists of OAuth scopes used in the oauthbreaker token requests. (Optional) **TLS:** - `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### New Consumers and Offset Reset Policy When a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters: - If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message. - If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset. ### Example Your kafka cluster no SASL/TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest ``` Your kafka cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "plaintext" username: "admin" password: "admin" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` Your kafka cluster turn on SASL OAuthbearer/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-kafka-secrets namespace: default data: sasl: "oauthbearer" username: "admin" password: "admin" oauthTokenEndpointUri: "https://tokenendpoint.com/token" scopes: "default" tls: "enable" ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-kafka-credential namespace: default spec: secretTargetRef: - parameter: sasl name: keda-kafka-secrets key: sasl - parameter: username name: keda-kafka-secrets key: username - parameter: password name: keda-kafka-secrets key: password - parameter: oauthTokenEndpointUri name: keda-kafka-secrets key: oauthTokenEndpointUri - parameter: scopes name: keda-kafka-secrets key: scopes - parameter: tls name: keda-kafka-secrets key: tls - parameter: ca name: keda-kafka-secrets key: ca - parameter: cert name: keda-kafka-secrets key: cert - parameter: key name: keda-kafka-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kafka-scaledobject namespace: default spec: scaleTargetRef: name: azure-functions-deployment pollingInterval: 30 triggers: - type: kafka metadata: bootstrapServers: localhost:9092 consumerGroup: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" offsetResetPolicy: latest authenticationRef: name: keda-trigger-auth-kafka-credential ``` ================================================ FILE: content/docs/2.9/scalers/artemis.md ================================================ +++ title = "ActiveMQ Artemis" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on ActiveMQ Artemis queues" go_file = "artemis_scaler" +++ ### Trigger Specification This specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues. ```yaml triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" brokerName: "artemis-activemq" brokerAddress: "test" queueLength: '10' activationQueueLength: '1' username: 'ARTEMIS_USERNAME' password: 'ARTEMIS_PASSWORD' restApiTemplate: # Optional. Default : "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" ``` **Parameter list:** - `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `:` format. - `queueName` - Name of the queue to check for the number of messages available. - `brokerName` - Name of the broker as defined in Artemis. - `brokerAddress` - Address of the broker. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `restApiTemplate` - Template to build REST API url to get queue size. (Default: `"http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount"`, Optional) - `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `"http://<>"`, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint. **Username and Password based authentication:** - `username` - The username to use to connect to the broker's management endpoint. - `password` - The password to use to connect to the broker's management endpoint. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: kedartemis namespace: kedartemis labels: app: kedartemis type: Opaque data: artemis-password: "YXJ0ZW1pcw==" artemis-username: "YXJ0ZW1pcw==" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedartemis namespace: kedartemis spec: secretTargetRef: - parameter: username name: kedartemis key: artemis-username - parameter: password name: kedartemis key: artemis-password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedartemis-consumer-scaled-object namespace: kedartemis spec: scaleTargetRef: name: kedartemis-consumer triggers: - type: artemis-queue metadata: managementEndpoint: "artemis-activemq.artemis:8161" queueName: "test" queueLength: "50" brokerName: "artemis-activemq" brokerAddress: "test" restApiTemplate: # Optional. Default: "http://<>/console/jolokia/read/org.apache.activemq.artemis:broker=\"<>\",component=addresses,address=\"<>\",subcomponent=queues,routing-type=\"anycast\",queue=\"<>\"/MessageCount" authenticationRef: name: trigger-auth-kedartemis ``` ================================================ FILE: content/docs/2.9/scalers/aws-cloudwatch.md ================================================ +++ title = "AWS CloudWatch" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS CloudWatch." go_file = "aws_cloudwatch_scaler" +++ ### Trigger Specification This specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch. ```yaml triggers: - type: aws-cloudwatch metadata: # Required: namespace namespace: AWS/SQS # Optional: Dimension Name dimensionName: QueueName # Optional: Dimension Value dimensionValue: keda # Optional: Expression query expression: SELECT MAX("ApproximateNumberOfMessagesVisible") FROM "AWS/SQS" WHERE QueueName = 'keda' metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "1.5" # Required: region awsRegion: "eu-west-1" # Optional: AWS endpoint url awsEndpoint: "" # Optional: AWS Access Key ID, can use TriggerAuthentication as well awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID # Optional: AWS Secret Access Key, can use TriggerAuthentication as well awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY identityOwner: pod | operator # Optional. Default: pod # Optional: Collection Time metricCollectionTime: "300" # default 300 # Optional: Metric Statistic metricStat: "Average" # default "Average" # Optional: Metric Statistic Period metricStatPeriod: "300" # default 300 # Optional: Metric Unit metricUnit: "Count" # default "" # Optional: Metric EndTime Offset metricEndTimeOffset: "60" # default 0 ``` **Parameter list:** - `awsRegion` - AWS Region for the AWS Cloudwatch. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `dimensionName` - Supports specifying multiple dimension names by using ";" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified) - `dimensionValue` - Supports specifying multiple dimension values by using ";" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified) - `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified) - `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required. - `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional) - `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional) - `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional) - `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional) - `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional) - `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float) - `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float) - `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read data from AWS CloudWatch. ### IAM Permissions The user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCloudWatchGetMetricData", "Effect": "Allow", "Action": "cloudwatch:GetMetricData", "Resource": "*" } ] } ``` For more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html). ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-cloudwatch-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-cloudwatch metadata: namespace: AWS/SQS dimensionName: QueueName dimensionValue: keda metricName: ApproximateNumberOfMessagesVisible targetMetricValue: "2.1" minMetricValue: "0" awsRegion: "eu-west-1" authenticationRef: name: keda-trigger-auth-aws-credentials ``` ================================================ FILE: content/docs/2.9/scalers/aws-dynamodb-streams.md ================================================ +++ title = "AWS DynamoDB Streams" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on AWS DynamoDB Streams" go_file = "aws_dynamodb_streams_scaler" +++ ### Trigger Specification This specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams. ```yaml triggers: - type: aws-dynamodb-streams metadata: # Required: awsRegion awsRegion: "ap-northeast-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Optional targetValue shardCount: "2" # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target DynamoDB table to which the stream belongs. - `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-streams-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb-streams authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: ap-northeast-1 tableName: keda-events shardCount: "2" ``` ================================================ FILE: content/docs/2.9/scalers/aws-dynamodb.md ================================================ +++ title = "AWS DynamoDB" availability = "v2.7+" maintainer = "Community" description = "Scale applications based on the records count in AWS DynamoDB" go_file = "aws_dynamodb_scaler" +++ ### Trigger Specification This specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload. ```yaml triggers: - type: aws-dynamodb metadata: # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Required: tableName tableName: myTableName # Required: targetValue targetValue: "1" # Required: expressionAttributeNames expressionAttributeNames: '{ "#k" : "partition_key_name"}' # Required: keyConditionExpression keyConditionExpression: "#k = :key" # Required: expressionAttributeValues expressionAttributeValues: '{ ":key" : {"S":"partition_key_target_value"}}' # Optional. Default: pod identityOwner: pod | operator ``` **Parameter list:** - `awsRegion` - AWS Region for the DynamoDB Table. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `tableName` - The target table where the scaler execute the query. - `targetValue` - The target value for the number of items retrieved by the query. - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON. - `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action. - `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON. - `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using IAM Role ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: default spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-dynamodb-table-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-dynamodb authenticationRef: name: keda-trigger-auth-aws-credentials metadata: awsRegion: eu-west-2 tableName: keda-events expressionAttributeNames: '{ "#k" : "event_type"}' keyConditionExpression: "#k = :key" expressionAttributeValues: '{ ":key" : {"S":"scaling_event"}}' targetValue: "5" ``` ================================================ FILE: content/docs/2.9/scalers/aws-kinesis.md ================================================ +++ title = "AWS Kinesis Stream" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on AWS Kinesis Stream." go_file = "aws_kinesis_stream_scaler" +++ ### Trigger Specification This specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream. ```yaml triggers: - type: aws-kinesis-stream metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" # Optional: Default: 2 shardCount: "2" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `streamName` - Name of AWS Kinesis Stream. - `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional) - `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `awsRegion` - AWS Region for the Kinesis Stream. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication). #### Delegate auth with TriggerAuthentication **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets namespace: keda-test data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-kinesis-stream-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-kinesis-stream authenticationRef: name: keda-trigger-auth-aws-credentials metadata: # Required streamName: myKinesisStream # Required awsRegion: "eu-west-1" # Optional: Default: 2 shardCount: "2" ``` ================================================ FILE: content/docs/2.9/scalers/aws-sqs.md ================================================ +++ title = "AWS SQS Queue" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on AWS SQS Queue." go_file = "aws_sqs_queue_scaler" +++ ### Trigger Specification This specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue. ```yaml triggers: - type: aws-sqs-queue metadata: # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter queueLength: "5" # Default: "5" # Required: awsRegion awsRegion: "eu-west-1" # Optional: awsEndpoint awsEndpoint: "" identityOwner: pod | operator # Optional. Default: pod ``` **Parameter list:** - `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter) - `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter) - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) > For the purposes of scaling, the default formula for "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. - `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well. - When set to `false` "actual messages" is equal to `ApproximateNumberOfMessages`. When set to `true` "actual messages" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true) - `awsRegion` - AWS Region for the SQS Queue. - `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `""`, Optional) - `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional) > When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required. ### Authentication Parameters > These parameters are relevant only when `identityOwner` is set to `pod`. You can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials. **Pod identity based authentication:** - `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider. **Role based authentication:** - `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. **Credential based authentication:** - `awsAccessKeyID` - Id of the user. - `awsSecretAccessKey` - Access key for the user to authenticate with. - `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html). The user will need access to read properties from the specified AWS SQS queue. ### Example #### Scaling a deployment using podIdentity providers ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: podIdentity: provider: aws-kiam # or aws-eks when using IRSA --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Role When you need to specify the IAM Role used to access the sqs queue. ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ROLE_ARN: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsRoleArn # The property in KEDA. name: test-secrets # The name of the kubernetes secret. key: AWS_ROLE_ARN # The key from the kubernetes secret. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling a deployment using IAM Users ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" ``` #### Scaling on ApproximateNumberOfMessages only ```yaml apiVersion: v1 kind: Secret metadata: name: test-secrets data: AWS_ACCESS_KEY_ID: # Required. AWS_SECRET_ACCESS_KEY: # Required. AWS_SESSION_TOKEN: # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-aws-credentials namespace: keda-test spec: secretTargetRef: - parameter: awsAccessKeyID # Required. name: test-secrets # Required. key: AWS_ACCESS_KEY_ID # Required. - parameter: awsSecretAccessKey # Required. name: test-secrets # Required. key: AWS_SECRET_ACCESS_KEY # Required. - parameter: awsSessionToken # Required when using temporary credentials. name: test-secrets # Required when using temporary credentials. key: AWS_SESSION_TOKEN # Required when using temporary credentials. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: aws-sqs-queue-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment triggers: - type: aws-sqs-queue authenticationRef: name: keda-trigger-auth-aws-credentials metadata: queueURL: myQueue queueLength: "5" awsRegion: "eu-west-1" scaleOnInFlight: false ``` ================================================ FILE: content/docs/2.9/scalers/azure-app-insights.md ================================================ +++ title = "Azure Application Insights" availability = "v2.6+" maintainer = "Microsoft" description = "Scale applications based on Azure Application Insights metrics." go_file = "azure_app_insights_scaler" +++ ### Trigger Specification This specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric. ```yaml triggers: - type: azure-app-insights metadata: metricAggregationTimespan: "0:1" metricAggregationType: avg metricFilter: cloud/roleName eq 'role_name' metricId: "customMetrics/example-metric" targetValue: "1.5" activationTargetValue: "5.5" activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private appInsightsResourceURL: https://api.applicationinsights.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` This scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page for further details. **Parameter list:** - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm"`. - `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal. - `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance. - `activeDirectoryClientPassword` - Password of the Active Directory client password. - `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional) - `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional) - `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional) - `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional) ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. - `applicationInsightsId` - Id of the Application Insights instance to query. - `tenantId` - Id of the tenant that contains the Azure resource. The principal will need `Monitoring Reader` access to query metrics from the Application Insights instance. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity. ### Example The following example illustrates the use of a TriggerAuthentication to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-app-insights-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-app-insights-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-app-insights-secrets key: activeDirectoryClientPassword - parameter: applicationInsightsId name: azure-app-insights-secrets key: applicationInsightsId - parameter: tenantId name: azure-app-insights-secrets key: tenantId # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" authenticationRef: name: azure-app-insights-trigger-auth ``` The following example illustrates the use of environment variables to connect to Application Insights. ```yaml apiVersion: v1 kind: Secret metadata: name: azure-app-insights-secrets type: Opaque data: activeDirectoryClientId: activeDirectoryClientPassword: applicationInsightsId: tenantId: --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-app-insights-example spec: replicas: 0 selector: matchLabels: app: azure-app-insights-example template: metadata: labels: app: azure-app-insights-example spec: containers: - name: example image: nginx:1.16.1 env: - name: ACTIVE_DIRECTORY_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientId - name: ACTIVE_DIRECTORY_PASSWORD valueFrom: secretKeyRef: name: azure-app-insights-secrets key: activeDirectoryClientPassword - name: APP_INSIGHTS_APP_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: applicationInsightsId - name: TENANT_ID valueFrom: secretKeyRef: name: azure-app-insights-secrets key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-app-insights-scaler spec: scaleTargetRef: name: azure-app-insights-example pollingInterval: 5 cooldownPeriod: 5 minReplicaCount: 0 maxReplicaCount: 2 triggers: - type: azure-app-insights metadata: metricId: "customMetrics/example-metric" metricAggregationTimespan: "0:5" metricAggregationType: avg metricFilter: cloud/roleName eq 'example' targetValue: "1" activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID tenantIdFromEnv: TENANT_ID ``` ================================================ FILE: content/docs/2.9/scalers/azure-data-explorer.md ================================================ +++ title = "Azure Data Explorer" availability = "v2.7+" maintainer = "Microsoft" description = "Scale applications based on Azure Data Explorer query result." go_file = "azure_data_explorer_scaler" +++ ### Trigger Specification This specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result. ```yaml triggers: - type: azure-data-explorer metadata: endpoint: https://keda.eastus.kusto.windows.net databaseName: kedadb query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "10.5" activationThreshold: "10.5" tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well clientSecret: t0p-s3cret # Can use TriggerAuthentication as well # Alternatively, you can use existing environment variables to read aad app creds from: clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter. clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter. tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `endpoint` - The endpoint to query your Data Explorer Cluster. - `databaseName` - The name of the Data Explorer Database to query. - `query` - Data Explorer query. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantId` - Id of the Azure AD tenant. - `clientId` - Id of the Azure AD application. - `clientSecret` - Password of the Azure AD application. - `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional) ### Query Guidance It is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query. The only supported data types for your query result are `real`, `int` or `long`. Be careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it. ### Authentication Parameters You can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. The AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster. 💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI. **Credential based authentication:** - `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal. - `clientSecret` - Password of the Azure AD application. - `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Examples ### Use TriggerAuthentication with Azure AD Application ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secret data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: secretTargetRef: - parameter: clientId name: azure-data-explorer-secret # Required. Refers to the name of the secret key: clientId - parameter: clientSecret name: azure-data-explorer-secret key: clientSecret - parameter: tenantId name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure Pod Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-data-explorer-trigger-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" authenticationRef: name: azure-data-explorer-trigger-auth ``` ### Use TriggerAuthentication with Azure AD Application through environment variables ```yaml apiVersion: v1 kind: Secret metadata: name: azure-data-explorer-secrets type: Opaque data: clientId: # Base64 encoded clientSecret: # Base64 encoded tenantId: # Base64 encoded --- apiVersion: apps/v1 kind: Deployment metadata: name: azure-data-explorer-example spec: replicas: 0 selector: matchLabels: app: azure-data-explorer-example template: metadata: labels: app: azure-data-explorer-example spec: containers: - name: example image: nginx:1.16.1 env: - name: AAD_APP_CLIENT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientId - name: AAD_APP_SECRET valueFrom: secretKeyRef: name: azure-data-explorer-secret key: clientSecret - name: AAD_APP_TENANT_ID valueFrom: secretKeyRef: name: azure-data-explorer-secret key: tenantId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-data-explorer-scaler spec: scaleTargetRef: name: azure-data-explorer-example pollingInterval: 30 cooldownPeriod: 45 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: azure-data-explorer metadata: clientIdFromEnv: AAD_APP_CLIENT_ID clientSecretFromEnv: AAD_APP_SECRET tenantIdFromEnv: AAD_APP_TENANT_ID databaseName: Weather endpoint: https://keda.eastus.kusto.windows.net query: | StormEvents | summarize StormCount = count() by State | top 1 by StormCount desc threshold: "1000" ``` ================================================ FILE: content/docs/2.9/scalers/azure-event-hub.md ================================================ +++ title = "Azure Event Hubs" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Event Hubs." go_file = "azure_eventhub_scaler" +++ ### Trigger Specification This specification describes the `azure-eventhub` trigger for Azure Event Hubs. ```yaml triggers: - type: azure-eventhub metadata: connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME consumerGroup: $Default unprocessedEventThreshold: '64' activationUnprocessedEventThreshold: '10' blobContainer: 'name_of_container' # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private endpointSuffix: servicebus.airgap.example # Required when cloud = Private storageEndpointSuffix: airgap.example # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ # Required when cloud = Private. eventHubResourceURL: https://eventhubs.airgap.example/ # Required when using pod identity authentication with blob storage storageAccountName: 'name_of_account' ``` **Parameter list:** - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=`. If the connection string does not end with `EntityPath=`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub. - `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity) - `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional) - `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional) - `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden. - `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional) - `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional) - `eventHubName` - Name of the Event Hub containing the messages. (Optional) - `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional) - `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.) - `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `""`, Optional) - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified. - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs. - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing. - `dapr` - Suitable for older Dapr pubsub and bindings - Compatible Dapr versions: - pubsub components: 1.6, 1.7, 1.8, 1.9 - bindings: 1.9 - For newer Dapr versions, use the `blobMetadata` strategy. - For older Dapr versions, use the `goSdk` strategy. - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see "Legacy checkpointing"). If this behaviour should be used, `blobContainer` is also required. - `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`). - `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.) - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`). - `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds). > 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour). > 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Event Hubs Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=;EntityPath=`. - `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information. > 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: nameOfTriggerAuth namespace: default spec: podIdentity: provider: Azure | azure-workload ``` When you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string. > 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required. ### Checkpointing Behaviour The list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored has changed with updates to the EventHub SDKs. * **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of the storage blob. This is the default behaviour when no `checkpointStrategy` is specified. This is applicable for the following scenarios: - .NET applications using `Microsoft.Azure.EventHubs` NuGet package. - Java applications using `azure-eventhubs-eph` package. - Python applications using `azure-eventhub` package below v5. * **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on the storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`. This is applicable for the following scenarios: - .NET applications using `Azure.Messaging.EventHubs` NuGet package. - Python applications using `azure-eventhub` v5. - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5. - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3. > 💡 `blobContainer` name is required for applications following legacy behaviour. > 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-eventhub-scaledobject namespace: default spec: scaleTargetRef: name: azureeventhub-function triggers: - type: azure-eventhub metadata: # Required storageConnectionFromEnv: AzureWebJobsStorage # Required if not using Pod Identity connectionFromEnv: EventHub # Required if using Pod Identity eventHubNamespace: AzureEventHubNameSpace eventHubName: NameOfTheEventHub # Optional consumerGroup: $Default # default: $Default unprocessedEventThreshold: '64' # default 64 events. blobContainer: ehcontainer ``` ================================================ FILE: content/docs/2.9/scalers/azure-log-analytics.md ================================================ +++ title = "Azure Log Analytics" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Log Analytics query result" go_file = "azure_log_analytics_scaler" +++ ### Trigger Specification This specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata: ```yaml triggers: - type: azure-log-analytics metadata: tenantId: "AZURE_AD_TENANT_ID" clientId: "SERVICE_PRINCIPAL_CLIENT_ID" clientSecret: "SERVICE_PRINCIPAL_PASSWORD" workspaceId: "LOG_ANALYTICS_WORKSPACE_ID" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "10.7" activationThreshold: "1.7" # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter. clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter. tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter. clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter. # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private logAnalyticsResourceURL: https://api.loganalytics.airgap.io/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. - `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes. - `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId) - `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). The authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional) - `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional) - `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional) - `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional) > 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`; it's not the full `id`! the example `az` command below can be used. ```sh az monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,"workspaceID (customerId)":customerId}' -o table ``` ### Query Guidance It is important to design your query to return 1 table with 1 row. A good practice is to add "| limit 1" at the end of your query. Scaler will take value from: - 1st cell as Metrics Value. - 2nd cell as Threshold (optional). You can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query. Data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64. Be careful with setting up "pollingInterval" and long-running queries. Test your query before. Example query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod. ```kusto let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient ``` Example result: ![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png) ### Scaler Limitations - As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers. **Service Principal based authentication:** - `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. - `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. - `clientSecret` - Password from your Azure AD Application/service principal. - `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. **Managed identity based authentication:** You can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service. [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example #### Service Principal based authentication ```yaml apiVersion: v1 kind: Secret metadata: name: kedaloganalytics namespace: kedaloganalytics labels: app: kedaloganalytics type: Opaque data: tenantId: "QVpVUkVfQURfVEVOQU5UX0lE" #Base64 encoded Azure Active Directory tenant id clientId: "U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE" #Base64 encoded Application id from your Azure AD Application/service principal clientSecret: "U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=" #Base64 encoded Password from your Azure AD Application/service principal workspaceId: "TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=" #Base64 encoded Log Analytics workspace id --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: secretTargetRef: - parameter: tenantId name: kedaloganalytics key: tenantId - parameter: clientId name: kedaloganalytics key: clientId - parameter: clientSecret name: kedaloganalytics key: clientSecret - parameter: workspaceId name: kedaloganalytics key: workspaceId --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` #### Managed identity based authentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: trigger-auth-kedaloganalytics namespace: kedaloganalytics spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: kedaloganalytics-consumer-scaled-object namespace: kedaloganalytics labels: deploymentName: kedaloganalytics-consumer spec: scaleTargetRef: kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet name: kedaloganalytics-consumer pollingInterval: 30 cooldownPeriod: 30 minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-log-analytics metadata: workspaceId: "81963c40-af2e-47cd-8e72-3002e08aa2af" query: | let AppName = "web"; let ClusterName = "demo-cluster"; let AvgDuration = ago(10m); let ThresholdCoefficient = 0.8; Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuUsageNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName | join (Perf | where InstanceName contains AppName | where InstanceName contains ClusterName | where CounterName == "cpuLimitNanoCores" | where TimeGenerated > AvgDuration | extend AppName = substring(InstanceName, indexof((InstanceName), "/", 0, -1, 10) + 1) | summarize arg_max(TimeGenerated, *) by AppName, CounterName | project Limit = CounterValue, TimeGenerated, CounterPath, AppName) on AppName | project MetricValue, Threshold = Limit * ThresholdCoefficient threshold: "1900000000" authenticationRef: name: trigger-auth-kedaloganalytics ``` ### Guides #### Enabling managed identity authentication for Log Analytics scaler Use the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\update KEDA: ```sh export SUBSCRIPTION_ID="" export RESOURCE_GROUP="" export CLUSTER_NAME="" export CLUSTER_LOCATION="" # "westeurope", "northeurope"... export IDENTITY_NAME="" #Any name export LOG_ANALYTICS_RESOURCE_ID="" # Login to Azure, set subscription, get AKS credentials az login az account set -s "${SUBSCRIPTION_ID}" az aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP} # ------- Cluster preparation. Run this block only once for fresh cluster. # Clone repo and run initial role assignment git clone https://github.com/Azure/aad-pod-identity.git ./aad-pod-identity/hack/role-assignment.sh #Deploy aad-pod-identity using Helm 3 helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts helm repo update helm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system # ------------------------------------------------------------------------------------------- #Create identity az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)" export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)" #Assign reader permissions for your identity to Log Analytics workspace #WARNING: It can take some time while identity will be provisioned. #If you see an error: "Principal SOME_ID does not exist in the directory SOME_ID", just wait couple of minutes and then retry. az role assignment create --role "Log Analytics Reader" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID} # Allow cluster to control identity created earlier. ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)" if [[ "${ID:-}" == "msi" ]]; then ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)" fi az role assignment create --role "Managed Identity Operator" --assignee "${ID}" --scope "${IDENTITY_RESOURCE_ID}" # Create AzureIdentity and AzureIdentityBinding cat < # Optional, can use TriggerAuthentication as well activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well # Optional (Default: AzurePublicCloud) cloud: Private # Required when cloud = Private azureResourceManagerEndpoint: https://management.azure.airgap.com/ # Required when cloud = Private. activeDirectoryEndpoint: https://login.airgap.example/ ``` **Parameter list:** - `resourceURI` - Shortened URI to the Azure resource with format `"//"`. - `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication. - `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI. - `resourceGroupName` - Name of the resource group for the Azure resource. - `metricName` - Name of the metric to query. - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview). - `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric. - `targetValue` - Target value to trigger scaling actions. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). - `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional) - `metricAggregationInterval` - Collection time of the metric in format `"hh:mm:ss"` (Default: `"0:5:0"`, Optional) - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional) - `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional) - `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional) - `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`). - `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`). Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity. **Credential based authentication:** - `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. - `activeDirectoryClientPassword` - Password of the Active Directory application. The user will need access to read data from the Azure resource. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: azure-monitor-secrets data: activeDirectoryClientId: activeDirectoryClientPassword: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-monitor-trigger-auth spec: secretTargetRef: - parameter: activeDirectoryClientId name: azure-monitor-secrets key: activeDirectoryClientId - parameter: activeDirectoryClientPassword name: azure-monitor-secrets key: activeDirectoryClientPassword # or Pod Identity, kind: Secret is not required in case of pod Identity podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-monitor-scaler spec: scaleTargetRef: name: azure-monitor-example minReplicaCount: 1 maxReplicaCount: 10 triggers: - type: azure-monitor metadata: resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster tenantId: xxx-xxx-xxx-xxx-xxx subscriptionId: yyy-yyy-yyy-yyy-yyy resourceGroupName: azureMonitor metricName: pod_custom_metric metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics metricFilter: namespace eq 'default' metricAggregationInterval: "0:1:0" metricAggregationType: Average targetValue: "1" authenticationRef: name: azure-monitor-trigger-auth ``` ================================================ FILE: content/docs/2.9/scalers/azure-pipelines.md ================================================ +++ title = "Azure Pipelines" availability = "v2.3+" maintainer = "Microsoft" description = "Scale applications based on agent pool queues for Azure Pipelines." go_file = "azure_pipelines_scaler" +++ ### Trigger Specification This specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool. ```yaml triggers: - type: azure-pipelines metadata: # Optional: Name of the pool in Azure DevOps poolName: "{agentPoolName}" # Optional: Learn more in 'How to determine your pool ID' poolID: "{agentPoolId}" # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well organizationURLFromEnv: "AZP_URL" # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well personalAccessTokenFromEnv: "AZP_TOKEN" # Optional: Target queue length targetPipelinesQueueLength: "1" # Default 1 activationTargetPipelinesQueueLength: "5" # Default 0 # Optional: Parent template to read demands from parent: "{parent ADO agent name}" # Optional: Demands string to read demands from ScaledObject demands: "{demands}" authenticationRef: name: pipeline-trigger-auth ``` **Parameter list:** - `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured) - `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured) - `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization. - `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page). - `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional) - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods. - `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called "mavenagent-keda-template"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable "AZP_NAME" - `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker` > 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used. ### Authentication Parameters As an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration. **Personal Access Token Authentication:** - `organizationURL` - The URL of the Azure DevOps organization. - `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps. ### How to determine your pool ID There are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`. It is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL. The URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs` > Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id. Finally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`. ### Supporting demands in agents By default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length. Demands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool, for instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven; particularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature. - **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list. - **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored) Microsoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml) Please note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands. If you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline: ```yaml pool: - name: "{agentPoolName}" demands: - example-demands - another-demand -equals /bin/executable ``` Then, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object. KEDA will use the following evaluation order: 1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job. 2) If `parent` is set, KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request. 3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided. > Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent. #### How it works under the hood Azure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com//_apis/distributedtask/pools//jobrequests`. KEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition. Once it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent. ### Configuring the agent container Microsoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux Please use the script in Step 5 as the entrypoint for your agent container. You will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch. The if statement for cleanup is only required if you are using the auto-deployment parent template method. ``` print_header "4. Running Azure Pipelines agent..." trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" & wait $! ``` to ``` print_header "4. Running Azure Pipelines agent..." if ! grep -q "template" <<< "$AZP_AGENT_NAME"; then echo "Cleanup Traps Enabled" trap 'cleanup; exit 0' EXIT trap 'cleanup; exit 130' INT trap 'cleanup; exit 143' TERM fi chmod +x ./run-docker.sh # To be aware of TERM and INT signals call run.sh # Running it with the --once flag at the end will shut down the agent after the build is executed ./run-docker.sh "$@" --once & wait $! ``` ### Example for ScaledObject ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: pipeline-auth data: personalAccessToken: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: pipeline-trigger-auth namespace: default spec: secretTargetRef: - parameter: personalAccessToken name: pipeline-auth key: personalAccessToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-pipelines-scaledobject namespace: default spec: scaleTargetRef: name: azdevops-deployment minReplicaCount: 1 maxReplicaCount: 5 triggers: - type: azure-pipelines metadata: poolID: "1" organizationURLFromEnv: "AZP_URL" parent: "example-keda-template" demands: "maven,docker" authenticationRef: name: pipeline-trigger-auth ``` ###Example for Parent Deployment or StatefulSet ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: agent spec: replicas: 1 selector: matchLabels: app: agent spec: containers: - name: agent image: [SAME AS SCALED JOB] envFrom: - secretRef: name: ado-pat-tokens env: - name: AZP_AGENT_NAME value: example-keda-template # Matches Scaled Job Parent ``` ================================================ FILE: content/docs/2.9/scalers/azure-service-bus.md ================================================ +++ title = "Azure Service Bus" maintainer = "Microsoft" description = "Scale applications based on Azure Service Bus Queues or Topics." availability = "v1.0+" go_file = "azure_servicebus_scaler" +++ ### Trigger Specification This specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic. > ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically. ```yaml triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Optional, required when pod identity is used namespace: service-bus-namespace # Optional, can use TriggerAuthentication as well connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # Optional messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages activationMessageCount: "2" cloud: Private # Optional. Default: AzurePublicCloud endpointSuffix: servicebus.airgap.example # Required when cloud=Private ``` **Parameter list:** - `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on. - `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `queueName` - Name of the Azure Service Bus queue to scale on. (Optional) - `topicName` - Name of the Azure Service Bus topic to scale on. (Optional) - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified) - `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional) - `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional) - `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional). - `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`. > 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for the Azure Service Bus Namespace. The following formats are supported. - With **SharedAccessKey** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=;SharedAccessKey=` - With **SharedAccessSignature** - `Endpoint=sb://.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=&se=&skn=&sr=` Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information on using Shared Access Signatures. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example Here is an example of how to use managed identity: ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-servicebus-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-servicebus-queue-scaledobject namespace: default spec: scaleTargetRef: name: azure-servicebus-queue-function triggers: - type: azure-servicebus metadata: # Required: queueName OR topicName and subscriptionName queueName: functions-sbqueue # or topicName: functions-sbtopic subscriptionName: sbtopic-sub1 # Required: Define what Azure Service Bus to authenticate to with Managed Identity namespace: service-bus-namespace # Optional messageCount: "5" # default 5 cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud authenticationRef: name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.9/scalers/azure-storage-blob.md ================================================ +++ title = "Azure Blob Storage" availability = "v1.1+" maintainer = "Microsoft" description = "Scale applications based on the count of blobs in a given Azure Blob Storage container." notice = "As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs." go_file = "azure_blob_scaler" +++ ### Trigger Specification This specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed. ```yaml triggers: - type: azure-blob metadata: blobContainerName: functions-blob blobCount: '5' activationBlobCount: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name blobPrefix: myprefix blobDelimiter: /example cloud: Private endpointSuffix: blob.core.airgap.example # Required when cloud=Private recursive: false globPattern: glob-pattern ``` **Parameter list:** - `blobContainerName` - Name of container in an Azure Storage account. - `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional) - `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the container belongs to. - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional) - `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) - `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `""`) - `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern as metric value. (Default: `""`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`. You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod Identity Authentication** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. - `accountName` - Name of the Azure Storage Account. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-blob-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-blob-scaledobject namespace: default spec: scaleTargetRef: name: azureblob-function triggers: - type: azure-blob metadata: # Required blobContainerName: functionsblob # Optional, required when pod identity is used accountName: storage-account-name # Optional, connection OR authenticationRef that defines the connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment # or authenticationRef as defined below # # Optional blobCount: "5" # default 5 blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "/" # Optional, default: AzurePublicCloud cloud: AzureChinaCloud authenticationRef: name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.9/scalers/azure-storage-queue.md ================================================ +++ title = "Azure Storage Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on Azure Storage Queues." go_file = "azure_queue_scaler" +++ ### Trigger Specification This specification describes the `azure-queue` trigger for Azure Storage Queue. ```yaml triggers: - type: azure-queue metadata: queueName: orders queueLength: '5' activationQueueLength: '50' connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME accountName: storage-account-name cloud: AzureUSGovernmentCloud ``` **Parameter list:** - `queueName` - Name of the queue. - `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional) - `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string. - `accountName` - Name of the storage account that the queue belongs to. - `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`) When `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`. ### Authentication Parameters You can authenticate by using pod identity or connection string authentication. **Connection String Authentication:** - `connection` - Connection string for Azure Storage Account. **Pod identity based authentication:** [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: azure-queue-auth spec: podIdentity: provider: azure | azure-workload --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: azure-queue-scaledobject namespace: default spec: scaleTargetRef: name: azurequeue-function triggers: - type: azure-queue metadata: # Required queueName: functionsqueue # Optional, required when pod identity is used accountName: storage-account-name # Optional: connection OR authenticationRef that defines connection connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment # or authenticationRef as defined below # # Optional queueLength: "5" # default 5 cloud: Private endpointSuffix: queue.local.azurestack.external # Required when cloud=Private authenticationRef: name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter ``` ================================================ FILE: content/docs/2.9/scalers/cassandra.md ================================================ +++ title = "Cassandra" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on Cassandra query results." go_file = "cassandra_scaler" +++ ### Trigger Specification This specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query. ```yaml triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" keyspace: "test_keyspace" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" activationTargetQueryValue: "10" metricName: "test_keyspace" ``` **Parameter list:** - `username` - The username credential for connecting to the Cassandra instance. - `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`) - `clusterIPAddress` - The IP address or the host name of the Cassandra instance. - `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional) - `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional) - `keyspace` - The name of the keyspace used in Cassandra. - `query` - A Cassandra query that should return single numeric value. - `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `metricName` - Name to assign to the metric. (Default: `s-cassandra-`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s-cassandra-`, where `` is the index of the trigger in a ScaledObject) ### Authentication Parameters You can authenticate by using a password via `TriggerAuthentication` configuration. **Password Authentication:** - `password` - Password for configured user to login to the Cassandra instance. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: cassandra-secrets type: Opaque data: cassandra_password: CASSANDRA_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-cassandra-secret spec: secretTargetRef: - parameter: password name: cassandra-secrets key: cassandra_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cassandra-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: cassandra metadata: username: "cassandra" port: "9042" clusterIPAddress: "cassandra.default" consistency: "Quorum" protocolVersion: "4" query: "SELECT COUNT(*) FROM test_keyspace.test_table;" targetQueryValue: "1" metricName: "test_keyspace" authenticationRef: name: keda-trigger-auth-cassandra-secret ``` ================================================ FILE: content/docs/2.9/scalers/couchdb.md ================================================ +++ title = "CouchDB" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on CouchDB query results." go_file = "couchdb_scaler" +++ ### Trigger Specification This specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query. ```yaml triggers: - type: couchdb metadata: connectionStringFromEnv: "CONNECTION_STRING" host: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" ``` **Parameter list:** - `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set) - `query` - A CouchDB query that should return single numeric value. (Optional) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set) ### Authentication Parameters You can authenticate by using a username and password via `TriggerAuthentication` configuration. **ConnectionString:** - `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set) **Password Authentication:** - `password` - Password for configured user to login to the Couchdb instance. - `username` - Username for configured user to login to the Couchdb instance. ### Example Here is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: couchdb-secrets data: username: COUCHDB_USERNAME password: COUCHDB_PASSWORD --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-couchdb-secret spec: secretTargetRef: - parameter: password name: couchdb-secrets key: password - parameter: username name: couchdb-secrets key: username --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: couchdb-scaledobject spec: scaleTargetRef: name: nginx-deployment triggers: - type: couchdb metadata: hostname: "test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local" port: "5984" dbName: "animals" queryValue: "1" query: '{ "selector": { "feet": { "$gt": 0 } }, "fields": ["_id", "feet", "greeting"] }' activationQueryValue: "1" metricName: "global-metric" authenticationRef: name: keda-trigger-auth-couchdb-secret ``` ================================================ FILE: content/docs/2.9/scalers/cpu.md ================================================ +++ title = "CPU" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on cpu metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `cpu` trigger that scales based on cpu metrics. ```yaml triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets CPU utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cpu-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: cpu metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.9/scalers/cron.md ================================================ +++ title = "Cron" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on a cron schedule." go_file = "cron_scaler" +++ ### Trigger Specification This specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule. ```yaml triggers: - type: cron metadata: # Required timezone: Asia/Kolkata # The acceptable values would be a value from the IANA Time Zone Database. start: 0 6 * * * # At 6:00 AM end: 0 20 * * * # At 8:00 PM desiredReplicas: "10" ``` **Parameter list:** - `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). - `start` - Cron expression indicating the start of the cron schedule. - `end` - Cron expression indicating the end of the cron schedule. - `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule. > 💡 **Note:** `start`/`end` support ["Linux format cron"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow). > **Notice:** > **Start and end should not be same.** > > For example, the following schedule is not valid: > ```yaml > start: 0 6 * * * # At 6:00 AM > end: 0 6 * * * # also at 6:00 AM >``` ### How does it work? The CRON scaler allows you to define a time range in which you want to scale your workloads out/in. When the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration. ![](/img/scalers/cron/how-it-works.png) What the CRON scaler does **not** do, is scale your workloads based on a recurring schedule. ### Scale to 0 during off hours If you want to scale you deployment to 0 outside office hours / working hours, you need to set `minReplicaCount: 0` in the ScaledObject, and increase the replicas during work hours. That way the Deployment will be scaled to 0 outside that time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual scaling down will happen 5 minutes after the cron schedule `end` parameter. It's almost always an error to try to do the other way around, i.e. set `desiredReplicas: 0` in the cron trigger. > 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a "dynamic" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`. > Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics. #### TL;DR - Set `minReplicaCount` to 0 - Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount` - If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject` #### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "10" ``` #### Example: dynamic number of replicas (0 during night, between 1 and 4 during day) ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: cron-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment minReplicaCount: 0 maxReplicaCount: 4 cooldownPeriod: 300 triggers: - type: cron metadata: timezone: Asia/Kolkata start: 0 6 * * * end: 0 20 * * * desiredReplicas: "1" - type: cpu metricType: Utilization metadata: value: "80" ``` The deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00. ================================================ FILE: content/docs/2.9/scalers/datadog.md ================================================ +++ title = "Datadog" availability = "v2.6+" maintainer = "Community" description = "Scale applications based on Datadog." go_file = "datadog_scaler" +++ > 💡 **NOTE:** Take into account [API Datadog endpoints rate limits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining polling interval. For more detailed information about polling intervals check [the Polling intervals and Datadog rate limiting section](#polling-intervals-and-datadog-rate-limiting). ### Trigger Specification This specification describes the `datadog` trigger that scales based on a Datadog metric. ```yaml triggers: - type: datadog metricType: Value metadata: query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" queryValue: "7.75" activationQueryValue: "1.1" queryAggregator: "max" type: "global" # Deprecated in favor of trigger.metricType age: "120" timeWindowOffset: "30" lastAvailablePointOffset: "1" metricUnavailableValue: "1.5" ``` **Parameter list:** - `query` - The Datadog query to run. - `queryValue` - Value to reach to start scaling (This value can be a float). - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries) - `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional) - `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional) - `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional) - `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional) - `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float) > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Authentication Datadog requires both an API key and an APP key to retrieve metrics from your account. You should use `TriggerAuthentication` CRD to configure the authentication: **Parameter list:** - `apiKey` - Datadog API key. - `appKey` - Datadog APP key. - `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional) ### Example The example below uses the default KEDA polling interval (30 seconds). Take into account that [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the polling interval can accelerate reaching it. If your account has reached its rate limit, a relevant error will be logged in KEDA. ```yaml apiVersion: v1 kind: Secret metadata: name: datadog-secrets namespace: my-project type: Opaque data: apiKey: # Required: base64 encoded value of Datadog apiKey appKey: # Required: base64 encoded value of Datadog appKey datadogSite: # Optional: base64 encoded value of Datadog site --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-datadog-secret namespace: my-project spec: secretTargetRef: # Required: API key for your Datadog account - parameter: apiKey name: datadog-secrets key: apiKey # Required: APP key for your Datadog account - parameter: appKey name: datadog-secrets key: appKey # Optional: Datadog site. Default: "datadoghq.com" - parameter: datadogSite name: datadog-secrets key: datadogSite --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue metricType: "Value" metadata: # Required: datadog metric query query: "sum:trace.redis.command.hits{env:none,service:redis}.as_count()" # Required: according to the number of query result, to scale the TargetRef queryValue: "7" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "120" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` ## Polling intervals and Datadog rate limiting [API Datadog endpoints are rate limited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the state of the `ScaledObject` there are two different parameters to control how often (per `ScaledObject`) we query Datadog for a metric. When scaling from 0 to 1, the polling interval is controlled by KEDA, using [the `spec.pollingInterval` parameter in the `ScaledObject` definition](../concepts/scaling-deployments/#pollinginterval). For example, if this parameter is set to `60`, KEDA will poll Datadog for a metric value every 60 seconds while the number of replicas is 0. While scaling from 1 to N, on top of KEDA, the HPA will also poll regularly Datadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period` parameter to the `kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options), which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll Datadog for a metric value every 30 seconds while the number of replicas is between 1 and N. ## Multi-Query Support To reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated. When doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`). > 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query. ### Example 1 - Aggregating Similar Metrics Simple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense). ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: # Comma-seperated querys count as a single API call: query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)" # According to aggregated results, how to scale the TargetRef queryValue: "100" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "average" # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90 age: "600" # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window metricUnavailableValue: "0" authenticationRef: name: keda-trigger-auth-datadog-secret ``` The example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both. This works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example. ### Example 2 - Driving scale directly When wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale. This can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running. Following this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog # `AverageValue` tracks the query results divided by the number of running containers metricType: "AverageValue" metadata: # Comma-seperated queries count as a single API call: ## This example returns "http.requests" @ 180 requests-per-second per-pod, ## and "http.backlog" size of 30 per-pod query: "per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30" # Setting query value to 1 and metricType to "AverageValue" allows the metric to dictate the number of pods from it's own arthimetic. queryValue: "1" # How to aggregate results from multi-query queries. Default: 'max' queryAggregator: "max" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Using the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries. ## Cases of unexpected metrics value in DataDog API response ### Latest data point is unavailable By default Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue ### The value of last data point is inaccurate Datadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: datadog-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: datadog metricType: "AverageValue" metadata: query: "sum:trace.express.request.hits{*}.as_rate()" queryValue: "100" age: "90" metricUnavailableValue: "0" # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0 timeWindowOffset: "30" # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0 lastAvailablePointOffset: "1" authenticationRef: name: keda-trigger-auth-datadog-secret ``` Check [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue. ================================================ FILE: content/docs/2.9/scalers/elasticsearch.md ================================================ +++ title = "Elasticsearch" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on elasticsearch search template query result." go_file = "elasticsearch_scaler" +++ ### Trigger Specification This specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query. The trigger always requires the following information: ```yaml triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" passwordFromEnv: "ELASTIC_PASSWORD" index: "my-index" searchTemplateName: "my-search-template-name" parameters: "param1:value1;param2:value2" valueLocation: "hits.total.value" targetValue: "1.1" activationTargetValue: "5.5" ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes. - `username` - Username to authenticate with to Elasticsearch cluster. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster. - `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ). - `searchTemplateName` - The search template name to run. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud. **Password Authentication:** - `username` - Username to authenticate with to Elasticsearch cluster. - `password` - Password for configured user to login to Elasticsearch cluster. **Cloud ID and API Key Authentication:** [Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service. - `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud. - `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud. ### Example Here is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: elasticsearch-secrets type: Opaque data: password: cGFzc3cwcmQh --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-elasticsearch-secret spec: secretTargetRef: - parameter: password name: elasticsearch-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: elasticsearch-scaledobject spec: scaleTargetRef: name: "deployment-name" triggers: - type: elasticsearch metadata: addresses: "http://localhost:9200" username: "elastic" index: "my-index" searchTemplateName: "my-search-template" valueLocation: "hits.total.value" targetValue: "10" parameters: "dummy_value:1" authenticationRef: name: keda-trigger-auth-elasticsearch-secret ``` ================================================ FILE: content/docs/2.9/scalers/etcd.md ================================================ +++ title = "Etcd" availability = "v2.9+" maintainer = "Huawei Cloud" description = "Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode" go_file = "etcd_scaler" +++ ### Trigger Specification This specification describes the `etcd` trigger that scales based on an etcd key-value pair. ```yaml triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' activationValue: '0.5' watchProgressNotifyInterval: '600' ``` **Parameter list:** - `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`). - `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers. - `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together. **Credential based authentication:** **TLS:** - `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional) - `ca` - Certificate authority file for TLS client authentication. (Optional) - `cert` - Certificate for client authentication. (Optional) - `key` - Key for client authentication. (Optional) - `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional) ### Example Your etcd cluster no TLS auth: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' ``` Your etcd cluster turn on SASL/TLS auth: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-etcd-secrets namespace: default data: tls: ZW5hYmxl ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-etcd-credential namespace: default spec: secretTargetRef: - parameter: tls name: keda-etcd-secrets key: tls - parameter: ca name: keda-etcd-secrets key: ca - parameter: cert name: keda-etcd-secrets key: cert - parameter: key name: keda-etcd-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: etcd-scaledobject spec: scaleTargetRef: name: my-app-target pollingInterval: 30 triggers: - type: etcd metadata: endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379 watchKey: length value: '5.5' authenticationRef: name: keda-trigger-auth-etcd-credential ``` ================================================ FILE: content/docs/2.9/scalers/external-push.md ================================================ +++ title = "External Push" availability = "v2.0+" maintainer = "Microsoft" description = "Scale applications based on an external push scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external-push` trigger for an external push scaler. ```yaml triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` **Parameter list:** - `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) The entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`. > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: name namespace: namespace spec: scaleTargetRef: name: keda-node triggers: - type: external-push metadata: scalerAddress: external-scaler-service:8080 tlsCertFile: /path/to/tls/cert.pem # optional ``` ================================================ FILE: content/docs/2.9/scalers/external.md ================================================ +++ title = "External" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on an external scaler." go_file = "external_scaler" +++ ### Trigger Specification This specification describes the `external` trigger for an external scaler. ```yaml triggers: - type: external metadata: scalerAddress: external-scaler-service:8080 tlsCertFile : /path/to/tls/cert.pem ``` **Parameter list:** - `scalerAddress` - Address of the external scaler. Format must be `host:port`. - `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional) > For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md). ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: keda-redis-test spec: scaleTargetRef: name: keda-redis-node triggers: - type: external metadata: scalerAddress: redis-external-scaler-service:8080 address: REDIS_HOST password: REDIS_PASSWORD listName: mylist listLength: "5" ``` ================================================ FILE: content/docs/2.9/scalers/gcp-pub-sub.md ================================================ +++ title = "Google Cloud Platform‎ Pub/Sub" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Google Cloud Platform‎ Pub/Sub." go_file = "gcp_pubsub_scaler" +++ ### Trigger Specification This specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub. ```yaml triggers: - type: gcp-pubsub metadata: subscriptionSize: "5" # Deprecated, use mode and value fields instead mode: "SubscriptionSize" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge value: "5.5" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge activationValue: "10.5" # Optional - Default is 0 subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` The Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription. The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription. - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) `subscriptionName` defines the subscription that should be monitored. You can use different formulas: - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used. - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`. You can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`. The mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`. The `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`. Here's an [example](https://github.com/kedacore/sample-go-gcppubsub). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject namespace: keda-pubsub-test spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub metadata: mode: "SubscriptionSize" value: "5" subscriptionName: "mysubscription" # Required credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required ``` ### Example using TriggerAuthentication ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: pubsub-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Example using TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: subscriptionName: "input" # Required ``` ## Example using ClusterTriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: ClusterTriggerAuthentication metadata: name: keda-clustertrigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pubsub-scaledobject spec: scaleTargetRef: name: keda-pubsub-go triggers: - type: gcp-pubsub authenticationRef: name: keda-clustertrigger-auth-gcp-credentials kind: ClusterTriggerAuthentication metadata: subscriptionName: "input" # Required ``` ================================================ FILE: content/docs/2.9/scalers/gcp-stackdriver.md ================================================ +++ title = "Google Cloud Platform Stackdriver" availability = "2.7+" maintainer = "Community" description = "Scale applications based on a metric obtained from Stackdriver." go_file = "gcp_stackdriver_scaler" +++ ### Trigger Specification This specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver. ```yaml triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: '100.50' activationTargetValue: "10.5" # Optional - Default is 0 credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON alignmentPeriodSeconds: '60' alignmentAligner: mean alignmentReducer: none ``` **Parameter list:** - `projectId` - GCP project Id that contains the metric. - `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used. - `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) The `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics. The `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details. ### Timeseries alignment properties It is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values. For that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property. Valid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change. Valid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05. For more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro). ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject namespace: keda-gcp-stackdriver-test spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' targetValue: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-stackdriver-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-stackdriver-scaledobject spec: scaleTargetRef: name: keda-gcp-stackdriver-go triggers: - type: gcp-stackdriver authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: projectId: my-project-id filter: 'metric.type="storage.googleapis.com/network/received_bytes_count" AND resource.type="gcs_bucket" AND metric.label.method="WriteObject" AND resource.label.bucket_name="my-gcp-bucket"' ``` ================================================ FILE: content/docs/2.9/scalers/gcp-storage.md ================================================ +++ title = "Google Cloud Platform Storage" availability = "2.7+" maintainer = "Community" description = "Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket." go_file = "gcp_storage_scaler" +++ ### Trigger Specification This specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein. ```yaml triggers: - type: gcp-storage metadata: bucketName: test-bucket targetObjectCount: '100' activationTargetObjectCount: '10' # Optional maxBucketItemsToScan: '1000' credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional blobPrefix: # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : "" blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: "" ``` **Parameter list:** - `bucketName` - Name of the bucket in GCS. - `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional) - `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional) - `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `""`, Optional) - `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `""`, Optional) As counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`. The metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**. You can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`. - `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information. - `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information. ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON. **Credential based authentication:** - `GoogleApplicationCredentials` - Service account credentials in JSON. **Identity based authentication:** You can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject namespace: keda-gcp-storage-test spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage metadata: bucketName: "Transactions" targetObjectCount: "5" credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON ``` #### Use TriggerAuthentication with Kubernetes secret ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: secretTargetRef: - parameter: GoogleApplicationCredentials name: gcp-storage-secret # Required. Refers to the name of the secret key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" blobPrefix: blobsubpath # Default : "" blobDelimiter: "/" # Default: "" ``` #### Use TriggerAuthentication with GCP Identity ```yaml apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-gcp-credentials spec: podIdentity: provider: gcp --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: gcp-storage-scaledobject spec: scaleTargetRef: name: keda-gcp-storage-go triggers: - type: gcp-storage authenticationRef: name: keda-trigger-auth-gcp-credentials metadata: bucketName: "Transactions" targetObjectCount: "5" ``` ================================================ FILE: content/docs/2.9/scalers/graphite.md ================================================ +++ title = "Graphite" availability = "v2.5+" maintainer = "Community" description = "Scale applications based on metrics in Graphite." go_file = "graphite_scaler" +++ ### Trigger Specification This specification describes the `graphite` trigger that scales based on metrics in Graphite. ```yaml triggers: - type: graphite metadata: # Required serverAddress: http://:81 metricName: request-count # Note: name to identify the metric query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response threshold: '10.5' activationThreshold: '5' queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours ``` **Parameter list:** - `serverAddress` - Address of Graphite - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique - `query` - Query to run. - `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information. ### Authentication Parameters Graphite Scaler supports one type of authentication - basic authentication **Basic authentication:** - `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. ### Examples ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: graphite metadata: serverAddress: http://:81 metricName: LagMetric threshold: '100' query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1)) queryTime: '-1Minutes' ``` Here is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-graphite-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-graphite-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-graphite-secret key: username - parameter: password name: keda-graphite-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: graphite-scaledobject namespace: default labels: deploymentName: php-apache-graphite spec: cooldownPeriod: 10 maxReplicaCount: 5 minReplicaCount: 0 pollingInterval: 5 scaleTargetRef: name: php-apache-graphite triggers: - type: graphite metadata: authMode: "basic" metricName: https_metric query: https_metric queryTime: -1Hours serverAddress: http://:81 threshold: "100" authenticationRef: name: keda-graphite-creds ``` ================================================ FILE: content/docs/2.9/scalers/huawei-cloudeye.md ================================================ +++ title = "Huawei Cloudeye" availability = "v1.1+" maintainer = "Community" description = "Scale applications based on a Huawei Cloudeye." go_file = "huawei_cloudeye_scaler" +++ ### Trigger Specification This specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye. ```yaml triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB metricName: mb_l7_qps dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2 targetMetricValue: "5.5" activationTargetMetricValue: "1.5" minMetricValue: "1.1" # Deprecated ``` **Parameter list:** - `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32. - `metricName` - Name of the metric. - `dimensionName` - Name of the metric dimension. - `dimensionValue` - Value of the metric dimension. - `targetMetricValue` - Target value for your metric. (This value can be a float) - `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) - `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300) - `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional) - `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials. **Credential based authentication:** - `IdentityEndpoint` - Identity Endpoint. - `ProjectID` - Project ID. - `DomainID` - Id of domain. - `Domain` - Domain. - `Region` - Region. - `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional) - `AccessKey` - Id of the user. - `SecretKey` - Access key for the user to authenticate with. The user will need access to read data from Huawei Cloudeye. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-huawei-secrets namespace: keda-test data: IdentityEndpoint: ProjectID: DomainID: Region: Domain: AccessKey: SecretKey: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-huawei-credential namespace: keda-test spec: secretTargetRef: - parameter: IdentityEndpoint # Required. name: keda-huawei-secrets # Required. key: IdentityEndpoint # Required. - parameter: ProjectID # Required. name: keda-huawei-secrets # Required. key: ProjectID # Required. - parameter: DomainID # Required. name: keda-huawei-secrets # Required. key: DomainID # Required. - parameter: Region # Required. name: keda-huawei-secrets # Required. key: Region # Required. - parameter: Domain # Required. name: keda-huawei-secrets # Required. key: Domain # Required. - parameter: AccessKey # Required. name: keda-huawei-secrets # Required. key: AccessKey # Required. - parameter: SecretKey # Required. name: keda-huawei-secrets # Required. key: SecretKey # Required. --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: huawei-cloudeye-scaledobject namespace: keda-test spec: scaleTargetRef: name: nginx-deployment maxReplicaCount: 5 minReplicaCount: 2 triggers: - type: huawei-cloudeye metadata: namespace: SYS.ELB dimensionName: lbaas_instance_id dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2 metricName: mb_l7_qps targetMetricValue: "100" minMetricValue: "1" authenticationRef: name: keda-trigger-auth-huawei-credential ``` ================================================ FILE: content/docs/2.9/scalers/ibm-mq.md ================================================ +++ title = "IBM MQ" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on IBM MQ Queue" go_file = "ibmmq_scaler" +++ ### Trigger Specification This specification describes the `ibmmq` trigger for IBM MQ Queue. ```yaml triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages activationQueueDepth: # OPTIONAL - Activation queue depth target. Default: 0 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret ``` **Parameter list:** - `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`. - `queueManager` - Name of the queue manager from which messages will be consumed. - `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed. - `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional) - `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional) - `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to IBM MQ: **Authentication Parameters** - `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`. - `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager. - `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional) - `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional) ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: keda-ibmmq-secret data: ADMIN_USER: # REQUIRED - Admin Username ADMIN_PASSWORD: # REQUIRED - Admin Password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ibmmq-scaledobject namespace: default labels: deploymentName: ibmmq-deployment spec: scaleTargetRef: name: ibmmq-deployment pollingInterval: 5 # OPTIONAL - Default: 30 seconds cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds maxReplicaCount: 18 # OPTIONAL - Default: 100 triggers: - type: ibmmq metadata: host: # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint queueManager: # REQUIRED - Your queue manager queueName: # REQUIRED - Your queue name tlsDisabled: # OPTIONAL - Set 'true' to disable TLS. Default: false queueDepth: # OPTIONAL - Queue depth target for HPA. Default: 5 messages usernameFromEnv: # Optional: Provide admin username from env instead of as a secret passwordFromEnv: # Optional: Provide admin password from env instead of as a secret authenticationRef: name: keda-ibmmq-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-ibmmq-trigger-auth namespace: default spec: secretTargetRef: - parameter: username name: keda-ibmmq-secret key: ADMIN_USER - parameter: password name: keda-ibmmq-secret key: ADMIN_PASSWORD ``` ================================================ FILE: content/docs/2.9/scalers/influxdb.md ================================================ +++ title = "InfluxDB" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on InfluxDB queries" go_file = "influxdb_scaler" +++ ### Trigger Specification This specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query. ```yaml triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationName: influx-org organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in "Parameter List" section thresholdValue: '4.4' activationThresholdValue: '6.2' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authToken: some-auth-token authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in "Parameter List" section metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`) ``` **Parameter list:** - `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server. - `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target. - `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc. - `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target. - `serverURL` - Holds the url value of the InfluxDB server. - `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float) - `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against. - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters You can authenticate by using an authorization token. **Authorization Token Authentication:** - `authToken` - Authorization token for InfluxDB server. ### Example Below is an example of how to deploy a scaled object with the `InfluxDB` scale trigger. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: influxdb-scaledobject namespace: my-project spec: scaleTargetRef: name: nginx-worker triggers: - type: influxdb metadata: serverURL: http://influxdb:8086 organizationNameFromEnv: INFLUXDB_ORG_NAME thresholdValue: '4' activationThresholdValue: '6' query: | from(bucket: "bucket-of-interest") |> range(start: -12h) |> filter(fn: (r) => r._measurement == "stat") authTokenFromEnv: INFLUXDB_AUTH_TOKEN ``` ================================================ FILE: content/docs/2.9/scalers/kubernetes-workload.md ================================================ +++ title = "Kubernetes Workload" availability = "v2.4+" maintainer = "Community" description = "Scale applications based on the count of running pods that match the given selectors." go_file = "kubernetes_workload_scaler" +++ ### Trigger Specification ```yaml triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend' value: '0.5' activationValue: '3.1' ``` **Parameter list:** - `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them. - `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed. The count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`. ### Authentication Parameters The own KEDA's identity is used to list the pods, so no extra configuration is needed here. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: workload-scaledobject spec: scaleTargetRef: name: workload-deployment triggers: - type: kubernetes-workload metadata: podSelector: 'app=backend, deploy notin (critical, monolith)' value: '3' ``` ================================================ FILE: content/docs/2.9/scalers/liiklus-topic.md ================================================ +++ title = "Liiklus Topic" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Liiklus Topic." go_file = "liiklus_scaler" +++ ### Trigger Specification This specification describes the `liiklus` trigger for Liiklus Topic. ```yaml triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group topic: test-topic # Optional lagThreshold: "50" # Optional activationLagThreshold: "20" groupVersion: 1 ``` **Parameter list:** - `address` - Address of the gRPC liiklus API endpoint. - `group` - Name of consumer group. - `topic` - Topic to monitor and scale based on `lagThreshold`. - `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional) - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: liiklus-scaledobject namespace: default spec: scaleTargetRef: name: function-deployment pollingInterval: 30 triggers: - type: liiklus metadata: # Required address: localhost:6565 group: my-group # Make sure that this consumer group name is the same one as the one that is consuming topics topic: test-topic # Optional lagThreshold: "50" # Default value is set to 10 ``` ================================================ FILE: content/docs/2.9/scalers/loki.md ================================================ +++ title = "Loki" availability = "v2.9+" maintainer = "Community" description = "Scale applications based on Loki query result." go_file = "loki_scaler" +++ ### Trigger Specification This specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata: ```yaml triggers: - type: loki metadata: # Required fields: serverAddress: http://:3100 # Note: loki server URL query: sum(rate({filename="/var/log/syslog"}[1m])) # Note: query must return a vector/scalar single element response threshold: '0.7' # Optional fields: activationThreshold: '2.50' tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint ``` **Parameter list:** - `serverAddress` - URL of Loki server. - `query` - LogQL query to run. The query must return a vector/scalar single element response. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional) - `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional) - `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional) ### Authentication Parameters Loki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.) ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) ``` Here is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: bearerToken: "BEARER_TOKEN" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-loki-secret key: bearerToken --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "bearer" authenticationRef: name: keda-loki-creds ``` Here is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-loki-secret namespace: default data: username: dXNlcm5hbWU= password: cGFzc3dvcmQ= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-loki-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-loki-secret key: username - parameter: password name: keda-loki-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: loki-scaledobject namespace: default spec: maxReplicaCount: 12 scaleTargetRef: name: nginx triggers: - type: loki metadata: serverAddress: http://:3100 threshold: '0.7' query: sum(rate({filename="/var/log/syslog"}[1m])) authModes: "basic" authenticationRef: name: keda-loki-creds ``` ================================================ FILE: content/docs/2.9/scalers/memory.md ================================================ +++ title = "Memory" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on memory metrics." go_file = "cpu_memory_scaler" +++ > **Notice:** > - This scaler **requires prerequisites**. See the 'Prerequisites' section. > - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0. > - This scaler only applies to ScaledObject, not to Scaling Jobs. ### Prerequisites KEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum). - The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider. - The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs. ```yaml # a working example of resources with specified requests spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "128Mi" cpu: "500m" ``` ### Trigger Specification This specification describes the `memory` trigger that scales based on memory metrics. ```yaml triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue' value: "60" containerName: "" # Optional. You can use this to target a specific container in a pod ``` **Parameter list:** - `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`. - `value` - Value to trigger scaling actions for: - When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity). - `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified. > 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information. > 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead. ### Example The following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" ``` The following example targets memory utilization of a specific container (`foo`) in a pod. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: memory-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: memory metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue' metadata: value: "50" containerName: "foo" ``` ================================================ FILE: content/docs/2.9/scalers/metrics-api.md ================================================ +++ title = "Metrics API" availability = "v2.0+" maintainer = "Community" description = "Scale applications based on a metric provided by an API" go_file = "metrics_api_scaler" +++ ### Trigger Specification This specification describes the `metrics-api` trigger that scales based on a metric value provided by an API. This scaler allows users to utilize **any existing APIs** as a metric provider. Here is an example of trigger configuration using metrics-api scaler: ```yaml triggers: - type: metrics-api metadata: targetValue: "8.8" activationTargetValue: "3.8" url: "http://api:3232/api/v1/stats" valueLocation: "components.worker.tasks" ``` **Parameter list:** - `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`). - `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value. - `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) ### Authentication Parameters Metrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **API Key based authentication:** - `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration. - `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration. - `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here. - `apiKey` - API Key needed for authentication. **Basic authentication:** - `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. (Optional) **TLS authentication:** - `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. - `key` - Key for client authentication. (Optional) **Bearer authentication:** - `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`. ### Example Here is a full example of scaled object definition using Metric API trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' ``` When checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation` to access the value in response's payload. The above example expects that the API endpoint will return response similar to this one: ```json { "components": { "worker": { "tasks": 12, ... }, ... }, ... } ``` Assuming such response, Metrics API trigger will figure out that current metric value is 12. > 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. "123", "1.23", "10Mi"). Here is an example of a metric scaler with API Key based authentication, ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: apiKey: "APIKEY" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: apiKey name: keda-metric-api-secret key: apiKey --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "apiKey" method: "query" keyParamName: "QUERY_KEY" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: token: "PlaceYourTokenHere" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: token name: keda-metric-api-secret key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "bearer" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-metric-api-secret key: username - parameter: password name: keda-metric-api-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "basic" authenticationRef: name: keda-metric-api-creds ``` Here is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-metric-api-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-metric-api-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-metric-api-secret key: cert - parameter: key name: keda-metric-api-secret key: key - parameter: ca name: keda-metric-api-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: http-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: metrics-api metadata: targetValue: "7" url: "http://api:3232/components/stats" valueLocation: 'components.worker.tasks' authMode: "tls" authenticationRef: name: keda-metric-api-creds ``` ================================================ FILE: content/docs/2.9/scalers/mongodb.md ================================================ +++ title = "MongoDB" maintainer = "Community" description = "Scale applications based on MongoDB queries." availability = "v2.1+" go_file = "mongo_scaler" +++ ### Trigger Specification This specification describes the `mongodb` trigger that scales based on result of MongoDB query. ```yaml triggers: - type: mongodb metadata: # name of an environment variable containing a valid MongoDB connection string connectionStringFromEnv: MongoDB_CONNECTION_STRING # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name metricName: "global-metric" ``` Alternatively, you can configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mongodb metadata: # host name of the MongoDB server. Example of mongodb service: "mongodb-svc..svc.cluster.local" host: mongodb-svc.default.svc.cluster.local # port number of the MongoDB server. port: "27017" # username credential for connecting to the MongoDB server username: test_user # name of an environment variable containing a valid password for connecting to the MongoDB server passwordFromEnv: MongoDB_Password # Required: database name dbName: "test" # Required: collection name collection: "test_collection" # Required: query expr, used by filter data query: '{"region":"eu-1","state":"running","plan":"planA"}' # Required: according to the number of query result, to scale the TargetRef queryValue: "1" # Optional: according to the number of query result, the scaler is active activationQueryValue: "1" # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name. metricName: "global-metric" ``` >**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection** **Parameter list:** The `mongodb` trigger always requires the following information: - `dbName` - Name of the database. - `collection` - Name of the collection. - `query` - A MongoDB query that should return single numeric value. - `queryValue` - A threshold that will define when scaling should occur. - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) To connect to the MongoDB server, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server. When configuring with a connection string, you can use this URL format: ``` mongodb://:@mongodb-svc..svc.cluster.local:27017/ ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . ### Authentication Parameters As an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration. **Connection String Authentication:** - `connectionString` - Connection string for MongoDB server. **Password Authentication:** - `host` - The host name of the MongoDB server. - `port` - The port number of the MongoDB server. - `username` - Username to authenticate with to MongoDB database. - `password` - Password for the configured user to login to MongoDB server. - `dbName` - Name of the database. ### Example Here is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledJob metadata: name: mongodb-job spec: jobTargetRef: template: spec: containers: - name: mongodb-update image: 1314520999/mongodb-update:latest args: - --dataBase=test - --collection=test_collection imagePullPolicy: IfNotPresent restartPolicy: Never backoffLimit: 1 pollingInterval: 30 # Optional. Default: 30 seconds maxReplicaCount: 30 # Optional. Default: 100 successfulJobsHistoryLimit: 0 # Optional. Default: 100. How many completed jobs should be kept. failedJobsHistoryLimit: 10 # Optional. Default: 100. How many failed jobs should be kept. triggers: - type: mongodb metadata: dbName: "test" collection: "test_collection" query: '{"region":"eu-1","state":"running","plan":"planA"}' queryValue: "1" metricName: "global-metric" authenticationRef: name: mongodb-trigger --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: mongodb-trigger spec: secretTargetRef: - parameter: connectionString name: mongodb-secret key: connect --- apiVersion: v1 kind: Secret metadata: name: mongodb-secret type: Opaque data: connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA== ``` ================================================ FILE: content/docs/2.9/scalers/mssql.md ================================================ +++ title = "MSSQL" availability = "v2.2+" maintainer = "Microsoft" description = "Scale applications based on Microsoft SQL Server (MSSQL) query results." go_file = "mssql_scaler" +++ ### Trigger Specification This specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/). ```yaml triggers: - type: mssql metadata: connectionStringFromEnv: MSSQL_CONNECTION_STRING query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: "5.5" activationTargetValue: '5' metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}` ``` > 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats). Alternatively, you configure connection parameters explicitly instead of providing a connection string: ```yaml triggers: - type: mssql metadata: username: "kedaUser" passwordFromEnv: MSSQL_PASSWORD host: mssqlinst.namespace.svc.cluster.local port: "1433" # optional database: test_db_name query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" targetValue: 1 metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name` ``` The `mssql` trigger always requires the following information: - `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure. - `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float) - `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function. To connect to the MSSQL instance, you can provide either: - `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string. Or provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime): - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance. When configuring with a connection string, you can use either a URL format (note the URL encoding of special characters): ``` sqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks ``` Or the more traditional ADO format: ``` Server=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30; ``` You can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. ### Authentication parameters As an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration. **Connection string authentication:** - `connectionString` - The connection string for the MSSQL instance. **Password authentication:** - `host` - The hostname of the MSSQL instance endpoint. - `port` - The port number of the MSSQL instance endpoint. (default 1433) - `database` - The name of the database to query. - `username` - The username credential for connecting to the MSSQL instance. - `password` - The password credential for connecting to the MSSQL instance. ### Example The following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string. ```yaml apiVersion: v1 kind: Secret metadata: name: mssql-secrets type: Opaque data: mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format "Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mssql-secret spec: secretTargetRef: - parameter: connectionString name: mssql-secrets key: mssql-connection-string --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mssql-scaledobject spec: scaleTargetRef: name: consumer # e.g. the name of the resource to scale triggers: - type: mssql metadata: targetValue: 1 query: "SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mssql-secret ``` ================================================ FILE: content/docs/2.9/scalers/mysql.md ================================================ +++ title = "MySQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on MySQL query result." go_file = "mysql_scaler" +++ ### Trigger Specification This specification describes the `mysql` trigger that scales based on result of MySQL query. The trigger always requires the following information: - `query` - A MySQL query that should return single numeric value. - `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function. To provide information about how to connect to MySQL you can provide: - `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value. Or provide more detailed information: - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using connection string or password authentication. **Connection String Authentication:** - `connectionString` - Connection string for MySQL database. **Password Authentication:** - `host` - The host of the MySQL server. - `port` - The port of the MySQL server. - `dbName` - Name of the database. - `username` - Username to authenticate with to MySQL database. - `password` - Password for configured user to login to MySQL database. variables. ### Example Here is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`. ```yaml apiVersion: v1 kind: Secret metadata: name: mysql-secrets namespace: my-project type: Opaque data: mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-mysql-secret namespace: my-project spec: secretTargetRef: - parameter: connectionString name: mysql-secrets key: mysql_conn_str --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: mysql-scaledobject namespace: my-project spec: scaleTargetRef: name: worker triggers: - type: mysql metadata: queryValue: "4.4" activationQueryValue: "5.4" query: "SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'" authenticationRef: name: keda-trigger-auth-mysql-secret ``` ================================================ FILE: content/docs/2.9/scalers/nats-jetstream.md ================================================ +++ title = "NATS JetStream" layout = "scaler" availability = "v2.8+" maintainer = "Community" description = "Scale applications based on NATS JetStream." go_file = "nats_jetstream_scaler" +++ ### Trigger Specification This specification describes the `nats-jetstream` trigger for NATS JetStream. ```yaml triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint. - `account` - Name of the NATS account. "$G" is default when no account is configured. - `stream` - Name of the JS stream within the account. - `consumer` - Name of the consumer for a given stream. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters Not supported yet. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: nats-jetstream-scaledobject namespace: nats-jetstream spec: pollingInterval: 3 # Optional. Default: 30 seconds cooldownPeriod: 10 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 2 # Optional. Default: 100 scaleTargetRef: name: sub triggers: - type: nats-jetstream metadata: natsServerMonitoringEndpoint: "nats.nats.svc.cluster.local:8222" account: "$G" stream: "mystream" consumer: "pull_consumer" lagThreshold: "10" activationLagThreshold: "15" useHttps: "false" ``` ================================================ FILE: content/docs/2.9/scalers/nats-streaming.md ================================================ +++ title = "NATS Streaming" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on NATS Streaming." go_file = "stan_scaler" +++ ### Trigger Specification This specification describes the `stan` trigger for NATS Streaming. ```yaml triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" activationLagThreshold: "5" useHttps: "false" ``` **Parameter list:** - `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint. - `queueGroup` - Name of queue group of the subscribers. - `durableName` - Name of durability used by subscribers. - `subject` - Name of the channel. - `lagThreshold` - Average target value to trigger scaling actions. - `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional) ### Authentication Parameters You can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration. - `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: natsServerMonitoringEndpoint: "stan-nats-ss.stan.svc.cluster.local:8222" queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" useHttps: "false" ``` #### Example with TriggerAuthentication: ```yaml apiVersion: v1 kind: Secret metadata: name: stan-secret namespace: example type: Opaque data: stan_endpoint: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-stan-secret namespace: example spec: secretTargetRef: - parameter: natsServerMonitoringEndpoint name: stan-secret key: stan_endpoint --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: stan-scaledobject namespace: example spec: pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds minReplicaCount: 0 # Optional. Default: 0 maxReplicaCount: 30 # Optional. Default: 100 scaleTargetRef: name: gonuts-sub triggers: - type: stan metadata: queueGroup: "grp1" durableName: "ImDurable" subject: "Test" lagThreshold: "10" authenticationRef: name: keda-trigger-auth-stan-secret ``` ================================================ FILE: content/docs/2.9/scalers/new-relic.md ================================================ +++ title = "New Relic" availability = "2.6+" maintainer = "Community" description = "Scale applications based on New Relic NRQL" go_file = "newrelic_scaler" +++ ### Trigger Specification This specification describes the `new-relic` trigger that scales based on a New Relic metric. ```yaml triggers: - type: new-relic metadata: # Required: Account - Subaccount to run the query on account: '1234567' # Required: QueryKey - Api key to connect to New Relic queryKey: "NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx" # Optional: nrRegion - Region to query data for. Default value is US. region: "US" # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false. noDataError: "true" # Required: nrql nrql: "SELECT average(duration) from Transaction where appName='SITE'" # Required: threshold threshold: "50.50" # Optional: activationThreshold - Target value for activating the scaler. activationThreshold: "20.1" ``` **Parameter list:** - `account` - The account within New Relic that the request should be targeted against. - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional) - `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional) - `nrql` - The New Relic query that will be run to get the data requested. NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query. [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) - `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters You can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`. **Authentication:** - `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/) - `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger. - `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger. ### Example ```yaml apiVersion: v1 kind: Secret metadata: name: new-relic-secret namespace: my-project type: Opaque data: apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567 account: MTIzNDU2 # base64 encoding of the new relic account number 123456 region: VVM= # base64 encoding of the new relic region US --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-new-relic namespace: my-project spec: secretTargetRef: - parameter: queryKey name: new-relic-secret key: apiKey - parameter: account name: new-relic-secret key: account - parameter: region name: new-relic-secret key: region --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: newrelic-scaledobject namespace: keda spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: new-relic metadata: nrql: "SELECT average(duration) from Transaction where appName='SITE'" noDataError: "true" threshold: '1000' authenticationRef: name: keda-trigger-auth-new-relic ``` ================================================ FILE: content/docs/2.9/scalers/openstack-metric.md ================================================ +++ title = "OpenStack Metric" availability = "v2.3+" maintainer = "Community" description = "Scale applications based on a threshold reached by a specific measure from OpenStack Metric API." go_file = "openstack_metrics_scaler" +++ ### Trigger Specification This specification describes the `openstack-metric` trigger for OpenStack metrics. > The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric. It's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs. ```yaml triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric #required metricID: 003bb589-166d-439d-8c31-cbf098d863de #required aggregationMethod: "mean" #required granularity: 300 #required (seconds) threshold: "1.250" #required activationThreshold: "0.250" #optional timeout: 30 #optional ``` > Protocol (http or https) should always be provided when specifying URLs **Parameter list:** - `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://:///metric`. - `metricID` - The Id of the intended metric. - `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy). - `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60). - `threshold` - The target value that, when reached, will scale the application. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API. (Default: `30`, Optional) ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. #### Application Credentials - `authURL` - The Keystone authentication URL. The pattern is: `http://://`. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: metrics-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 timeout: 30 authenticationRef: name: openstack-metric-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: openstack-metric-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: openstack-metric-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-metric metadata: metricsURL: http://localhost:8041/v1/metric metricID: faf01aa5-da88-4929-905d-b83fbab46771 aggregationMethod: "mean" granularity: 300 threshold: 1250 authenticationRef: name: openstack-metric-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.9/scalers/openstack-swift.md ================================================ +++ title = "OpenStack Swift" availability = "v2.1+" maintainer = "Community" description = "Scale applications based on the count of objects in a given OpenStack Swift container." go_file = "openstack_swift_scaler" +++ ### Trigger Specification This specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container. ```yaml triggers: - type: openstack-swift metadata: containerName: my-container # Required swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78 # Optional objectCount: "2" # Optional activationObjectCount: "5" # Optional objectPrefix: "my-prefix" # Optional objectDelimiter: "/" # Optional objectLimit: "10" # Optional onlyFiles: "true" # Optional timeout: "2" # Optional ``` > Please, always provide the protocol (http or https) when specifying URLs. **Parameter list:** - `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional) - `containerName` - Name of Swift container in an OpenStack account. - `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional) - `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `""`, Optional) - `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `""`, Optional) - `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `""`, Optional) - `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional) - `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional) For more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/). ### Authentication Parameters To authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the "password" method or the "application credentials" method. Both cases use `TriggerAuthentication`. #### Password - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `userID` - The OpenStack project user ID. - `password` - The password for the provided user. - `projectID` - The OpenStack project ID. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. #### Application Credentials - `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler. - `appCredentialID` - The Application Credential ID. - `appCredentialSecret` - The Application Credential secret. - `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog. ### Example #### Password method Here is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-password namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU= password: YWRtaW4= projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc= regionName: Y2FsaWZvcm5pYS0x --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-password-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-password key: authURL - parameter: userID name: openstack-secret-password key: userID - parameter: password name: openstack-secret-password key: password - parameter: projectID name: openstack-secret-password key: projectID - parameter: regionName name: openstack-secret-password key: regionName --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: containerName: my-container objectCount: "1" onlyFiles: "true" authenticationRef: name: swift-password-trigger-authentication ``` #### Application Credentials method You can also use the Application Credentials method. ```yaml apiVersion: v1 kind: Secret metadata: name: openstack-secret-appcredentials namespace: default type: Opaque data: authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw== appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ= appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: swift-appcredentials-trigger-authentication namespace: default spec: secretTargetRef: - parameter: authURL name: openstack-secret-appcredentials key: authURL - parameter: appCredentialID name: openstack-secret-appcredentials key: appCredentialID - parameter: appCredentialSecret name: openstack-secret-appcredentials key: appCredentialSecret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: swift-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment pollingInterval: 10 cooldownPeriod: 10 minReplicaCount: 0 triggers: - type: openstack-swift metadata: swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87 containerName: my-container objectCount: "1" authenticationRef: name: swift-appcredentials-trigger-authentication ``` ================================================ FILE: content/docs/2.9/scalers/postgresql.md ================================================ +++ title = "PostgreSQL" availability = "v1.2+" maintainer = "Community" description = "Scale applications based on a PostgreSQL query." go_file = "postgresql_scaler" +++ ### Trigger Specification This specification describes the `postgresql` trigger that scales based on a PostgreSQL query The PostgreSQL scaler allows for two connection options: A user can offer a full connection string (often in the form of an environment variable secret) - `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value. Alternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. - `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace. - `userName:` - Username for postgresql user. - `passwordFromEnv` Password for postgresql user. - `port` - Postgresql port. - `dbName` - Postgresql Database name. - `sslmode` - SSL policy for communicating with database. Finally, a user inserts a query that returns the desired value. - `query` - What query to poll postgresql with. Query must return an integer. - `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float) - `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional) > Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function. This is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`: ```yaml triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "1.1" activationTargetQueryValue: "5" metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost` ``` While this is an example of specifying each parameter: ```yaml triggers: - type: postgresql metadata: userName: "kedaUser" passwordFromEnv: PG_PASSWORD host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA #lives in a different namespace from your postgres port: "5432" dbName: test_db_name sslmode: disable query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: "2.2" metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name` ``` ### Authentication Parameters You can authenticate by using a password or store the password within the connectionString. **Connection String Authentication:** - `connection` - Connection string for PostgreSQL database. **Password Authentication:** - `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace. - `userName` - Username for PostgreSQL user. - `password` Password for configured user to login to PostgreSQL database variables. - `port` - PostgreSQL port. - `dbName` - PostgreSQL Database name. - `sslmode` - SSL policy for communicating with database. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: airflow-worker spec: scaleTargetRef: name: airflow-worker pollingInterval: 10 # Optional. Default: 30 seconds cooldownPeriod: 30 # Optional. Default: 300 seconds maxReplicaCount: 10 # Optional. Default: 100 triggers: - type: postgresql metadata: connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB query: "SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';" targetQueryValue: 1 ``` ================================================ FILE: content/docs/2.9/scalers/predictkube.md ================================================ +++ title = "Predictkube" availability = "v2.6+" maintainer = "Dysnix" description = "AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS." go_file = "predictkube_scaler" +++ PredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling. To make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail. Review our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube. ### Trigger Specification This specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics. ```yaml triggers: - type: predictkube metadata: # Required fields: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) queryStep: "2m" threshold: '100.50' activationThreshold: '50.1' ``` **Parameter list:** - `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application. - `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data. - `prometheusAddress` - Address of Prometheus server. - `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response. - `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) ### Authentication Parameters Predictkube Scaler supports one type of authentication - authentication by API key. Prometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler. **Auth gateway based authentication:** - `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/) ### Example ```yaml --- apiVersion: v1 kind: Secret metadata: name: predictkube-secrets namespace: some-namespace type: Opaque data: apiKey: # Required: base64 encoded value of PredictKube apiKey bearerToken: "BEARER_TOKEN" # Optional: bearer authentication for Prometheus ca: "CUSTOM_CA_CERT" # Optional: certificate authority file for TLS client authentication for Prometheus --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-predictkube-secret namespace: some-namespace spec: secretTargetRef: # Required: API key for your predictkube account - parameter: apiKey name: predictkube-secrets key: apiKey # Optional: might be required if you're using bearer auth for Promethrus - parameter: bearerToken name: keda-prom-secret key: bearerToken # Optional: might be required if you're using a custom CA for Promethrus - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: predictkube-scaledobject namespace: some-namespace spec: scaleTargetRef: name: my-deployment kind: StatefulSet pollingInterval: 30 cooldownPeriod: 7200 minReplicaCount: 3 maxReplicaCount: 50 triggers: - type: predictkube metadata: predictHorizon: "2h" historyTimeWindow: "7d" prometheusAddress: http://:9090 query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response queryStep: "2m" # Note: query step duration for range prometheus queries threshold: "100" authModes: "bearer" # might be required if you're using bearer auth for Promethrus authenticationRef: name: keda-trigger-auth-predictkube-secret ``` ================================================ FILE: content/docs/2.9/scalers/prometheus.md ================================================ +++ title = "Prometheus" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Prometheus." go_file = "prometheus_scaler" +++ ### Trigger Specification This specification describes the `prometheus` trigger that scales based on a Prometheus. ```yaml triggers: - type: prometheus metadata: # Required fields: serverAddress: http://:9090 metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total` query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response threshold: '100.50' activationThreshold: '5.5' # Optional fields: namespace: example-namespace # for namespaced queries, eg. Thanos cortexOrgID: my-org # Optional. X-Scope-OrgID header for Cortex. ignoreNullValues: "false" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost unsafeSsl: "false" # Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint ``` **Parameter list:** - `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://:8481/select/0/prometheus` - `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique. - `query` - Query to run. - `threshold` - Value to start scaling for. (This value can be a float) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional) - `cortexOrgID` - The `X-Scope-OrgID` header to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional) - `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional) - `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs (Values: `true`,`false`, Default: `false`, Optional) ### Authentication Parameters Prometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication. You can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: "tls,basic"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below: **Bearer authentication:** - `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration. - `bearerToken`: The token needed for authentication. This is a required field. **Basic authentication:** - `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration. - `username` - This is a required field. Provide the username to be used for basic authentication. - `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty. **TLS authentication:** - `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration. - `ca` - Certificate authority file for TLS client authentication. - `cert` - Certificate for client authentication. This is a required field. - `key` - Key for client authentication. Optional. This is a required field. > 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA. ### Example ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: default spec: scaleTargetRef: name: my-deployment triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) ``` Here is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: bearerToken: "BEARER_TOKEN" ca: "CUSTOM_CA_CERT" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken # might be required if you're using a custom CA - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "bearer" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: username: "dXNlcm5hbWUK" # Must be base64 password: "cGFzc3dvcmQK" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "basic" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls" authenticationRef: name: keda-prom-creds ``` Here is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows ```yaml apiVersion: v1 kind: Secret metadata: name: keda-prom-secret namespace: default data: cert: "cert" key: "key" ca: "ca" username: "username" password: "password" --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds namespace: default spec: secretTargetRef: - parameter: cert name: keda-prom-secret key: cert - parameter: key name: keda-prom-secret key: key - parameter: ca name: keda-prom-secret key: ca - parameter: username name: keda-prom-secret key: username - parameter: password name: keda-prom-secret key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: prometheus-scaledobject namespace: keda labels: deploymentName: dummy spec: maxReplicaCount: 12 scaleTargetRef: name: dummy triggers: - type: prometheus metadata: serverAddress: http://:9090 metricName: http_requests_total threshold: '100' query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) authModes: "tls,basic" authenticationRef: name: keda-prom-creds ``` ================================================ FILE: content/docs/2.9/scalers/pulsar.md ================================================ +++ title = "Apache Pulsar" availability = "v2.8" maintainer = "Community" description = "Scale applications based on an Apache Pulsar topic subscription." go_file = "pulsar_scaler" layout = "scaler" +++ ### Trigger Specification This specification describes the `pulsar` trigger for an Apache Pulsar topic. ```yaml triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' activationMsgBacklogThreshold: '2' authModes: "" ``` **Parameter list:** - `adminURL` - Stats URL of the admin API for your topic. - `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}` - `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional) - `subscription` - Name of the topic subscription - `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10) - `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`,`basic`, Default: `""`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request) ### Authentication Parameters The authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec. **Bearer Auth** When configuring Bearer Authentication (Token Auth), configure the following: - `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer `. **Basic Auth** When configuring Basic Authentication, configure the following: - `username`: the username - `password`: the password (optional) **TLS:** When configuring mutual TLS authentication, configure the following: - `ca`: The trusted root Certificate authority used to validate the server's certificate. - `cert`: Certificate for client authentication. - `key`: Key for client authentication. ### TLS with custom CA Certificates When configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example. Before 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now. ### Examples #### No Authentication and No TLS ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: adminURL: http://localhost:80 topic: persistent://public/default/my-topic isPartitionedTopic: false subscription: sub1 msgBacklogThreshold: '5' ``` #### Only Mutual TLS Authentication ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: cert: key: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: cert name: keda-pulsar-secrets key: cert - parameter: key name: keda-pulsar-secrets key: key --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "tls" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Bearer Token with TLS via custom trusted CA Certificate In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: ca: token: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: ca name: keda-pulsar-secrets key: ca - parameter: bearerToken name: keda-pulsar-secrets key: token --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://localhost:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` #### Basic Auth with TLS Relying on Well Known Root CA In order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example also utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the `authModes` field only has `bearer`. ```yaml apiVersion: v1 kind: Secret metadata: name: keda-pulsar-secrets namespace: default data: username: password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-pulsar-credential namespace: default spec: secretTargetRef: - parameter: username name: keda-pulsar-secrets key: admin - parameter: password name: keda-pulsar-secrets key: password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: pulsar-scaledobject namespace: default spec: scaleTargetRef: name: pulsar-consumer pollingInterval: 30 triggers: - type: pulsar metadata: authModes: "bearer" adminURL: https://pulsar.com:8443 topic: persistent://public/default/my-topic subscription: sub1 msgBacklogThreshold: '5' authenticationRef: name: keda-trigger-auth-pulsar-credential ``` ================================================ FILE: content/docs/2.9/scalers/rabbitmq-queue.md ================================================ +++ title = "RabbitMQ Queue" availability = "v1.0+" maintainer = "Microsoft" description = "Scale applications based on RabbitMQ Queue." go_file = "rabbitmq_scaler" +++ ### Trigger Specification This specification describes the `rabbitmq` trigger for RabbitMQ Queue. ```yaml triggers: - type: rabbitmq metadata: host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication. protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto. mode: QueueLength # QueueLength or MessageRate value: "100.50" # message backlog or publish/sec. target per instance activationValue: "10.5" # Optional. Activation threshold queueName: testqueue vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter ``` **Parameter list:** - `host` - Host of RabbitMQ with format `://:/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication. - `queueName` - Name of the queue to read message from. - `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`) - `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`) - `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float) - `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional) - `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional) - `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger. - `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) - `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`) - `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional) - `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional) - `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol) - `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target. > 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request. > 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters. > 💡 **Note:** `mode: MessageRate` requires protocol `http`. > 💡 **Note:** `useRegex: "true"` requires protocol `http`. > ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted. > ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently. ### Authentication Parameters TriggerAuthentication CRD is used to connect and authenticate to RabbitMQ: - For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`. - For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`. > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports. ### Example #### AMQP protocol: ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format amqp://guest:password@localhost:5672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: amqp queueName: testqueue mode: QueueLength value: "20" metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue` authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`MessageRate` and `QueueLength`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: testqueue mode: QueueLength value: "20" authenticationRef: name: keda-trigger-auth-rabbitmq-conn - type: rabbitmq metadata: protocol: http queueName: testqueue mode: MessageRate value: "100" authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` #### HTTP protocol (`QueueLength`) and using regex (`useRegex`): ```yaml apiVersion: v1 kind: Secret metadata: name: keda-rabbitmq-secret data: host: # base64 encoded value of format http://guest:password@localhost:15672/vhost --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-rabbitmq-conn namespace: default spec: secretTargetRef: - parameter: host name: keda-rabbitmq-secret key: host --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-scaledobject namespace: default spec: scaleTargetRef: name: rabbitmq-deployment triggers: - type: rabbitmq metadata: protocol: http queueName: ^.*incoming$ mode: QueueLength value: "20" useRegex: "true" operation: max authenticationRef: name: keda-trigger-auth-rabbitmq-conn ``` ================================================ FILE: content/docs/2.9/scalers/redis-cluster-lists.md ================================================ +++ title = "Redis Lists (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Cluster topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster. ```yaml triggers: - type: redis-cluster metadata: addresses: localhost:6379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes. - `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-cluster metadata: addresses: node1:6379, node2:6379, node3:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.9/scalers/redis-cluster-streams.md ================================================ +++ title = "Redis Streams (supports Redis Cluster)" availability = "v2.1+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Cluster topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology. ```yaml triggers: - type: redis-cluster-streams metadata: addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "6379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Cluster nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`. - `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-cluster-streams metadata: address: node1:6379, node2:6379, node3:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.9/scalers/redis-lists.md ================================================ +++ title = "Redis Lists" availability = "v1.0+" maintainer = "Community" description = "Scale applications based on Redis Lists." go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis` trigger that scales based on the length of a list in Redis. ```yaml triggers: - type: redis metadata: address: localhost:6379 # Format must be host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server. - `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well. - `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) - `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0. Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a username (optional) and password. **Connection Authentication:** - `address` - The hostname and port for the Redis server (host:port format). - `host` - The hostname of the Redis server. If specified, the `port` should also be specified. - `port` - The port of the Redis server. If specified, the `host` should also be specified. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis metadata: address: localhost:6379 listName: mylist listLength: "10" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.9/scalers/redis-sentinel-lists.md ================================================ +++ title = "Redis Lists (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Lists scaler with support for Redis Sentinel topology" go_file = "redis_scaler" +++ ### Trigger Specification This specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel metadata: addresses: localhost:26379 # Comma separated list of the format host:port usernameFromEnv: REDIS_USERNAME # optional passwordFromEnv: REDIS_PASSWORD # optional sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional listName: mylist # Required listLength: "5" # Required activationListLength: "5" # optional enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes. - `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well. - `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well. - `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server. - `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server. - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively. - `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server. - `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `listName` - Name of the Redis List that you want to monitor. - `listLength` - Average target value to trigger scaling actions. - `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters You can authenticate by using a password. **Connection Authentication:** - `addresses` - Comma separated list of host:port format. - `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified. - `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified. - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. **Authentication:** - `username` - Redis username to authenticate with. - `password` - Redis password to authenticate with. **Sentinel Authentication:** - `sentinelUsername` - Redis Sentinel username to authenticate with. - `sentinelPassword` - Redis Sentinel password to authenticate with. ### Example Here is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`. You can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly. ```yaml apiVersion: v1 kind: Secret metadata: name: votes-db-secret namespace: my-project type: Opaque data: redis_username: YWRtaW4= redis_password: YWRtaW4= --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-redis-secret namespace: my-project spec: secretTargetRef: - parameter: username name: votes-db-secret key: redis_username - parameter: password name: votes-db-secret key: redis_password --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-scaledobject namespace: my-project spec: scaleTargetRef: name: votes triggers: - type: redis-sentinel metadata: addresses: node1:26379, node2:26379, node3:26379 listName: mylist listLength: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-trigger-auth-redis-secret ``` ================================================ FILE: content/docs/2.9/scalers/redis-sentinel-streams.md ================================================ +++ title = "Redis Streams (supports Redis Sentinel)" availability = "v2.5+" maintainer = "Community" description = "Redis Streams scaler with support for Redis Sentinel topology" go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup. ```yaml triggers: - type: redis-sentinel-streams metadata: addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port hosts: localhost # Comma separated lists of hosts. Required if address is not provided ports: "26379" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter ``` **Parameter list:** - `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`. > As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters. - `hosts` - Comma separated list of hosts of Redis Sentinel nodes. > It is not required if `addresses` has been provided. - `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes. > It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional) - `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional) - `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for. - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`. - `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target. - `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target. - `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: addressesFromEnv: REDIS_ADDRESSES usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-sentinel-streams metadata: address: node1:26379, node2:26379, node3:26379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" sentinelMaster: "mymaster" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.9/scalers/redis-streams.md ================================================ +++ title = "Redis Streams" availability = "v1.5+" maintainer = "Community" description = "Scale applications based on Redis Streams." go_file = "redis_streams_scaler" +++ ### Trigger Specification Redis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure. One of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages. This specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream. ```yaml triggers: - type: redis-streams metadata: address: localhost:6379 # Required if host and port are not provided. Format - host:port host: localhost # Required if address is not provided port: "6379" # Required if address is not provided and host has been provided. usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef) passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef) stream: my-stream # Required - name of the Redis Stream consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream pendingEntriesCount: "10" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream enableTLS: "false" # optional databaseIndex: "0" # optional # Alternatively, you can use existing environment variables to read configuration from: # See details in "Parameter list" section addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter ``` **Parameter list:** - `address` - The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`. > As an alternative to the `address` field, the user can specify `host` and `port` parameters. - `host` - The host of the Redis server. > It is not required if `address` has been provided. - `port` - The port of the Redis server. > It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided. - `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional) - `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional) - `stream` - Name of the Redis Stream. - `consumerGroup` - Name of the Consumer group associated with Redis Stream. - `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional) - `databaseIndex` - The Redis database index. Defaults to `0` if not specified. - `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional) Some parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables: - `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`. - `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target. - `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target. ### Authentication Parameters The scaler supports two modes of authentication: #### Using username/password authentication Use the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported. Here is an example: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: addressFromEnv: REDIS_HOST usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" ``` #### Using `TriggerAuthentication` You can use `TriggerAuthentication` CRD to configure the authentication. For example: ```yaml apiVersion: v1 kind: Secret metadata: name: redis-streams-auth type: Opaque data: redis_username: redis_password: --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-redis-stream-triggerauth spec: secretTargetRef: - parameter: username name: redis-streams-auth # name of the Secret key: redis_username # name of the key in the Secret - parameter: password name: redis-streams-auth # name of the Secret key: redis_password # name of the key in the Secret --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: redis-streams-scaledobject namespace: default spec: scaleTargetRef: name: redis-streams-consumer pollingInterval: 15 cooldownPeriod: 200 maxReplicaCount: 25 minReplicaCount: 1 triggers: - type: redis-streams metadata: address: localhost:6379 stream: my-stream consumerGroup: consumer-group-1 pendingEntriesCount: "10" authenticationRef: name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource ``` ================================================ FILE: content/docs/2.9/scalers/selenium-grid-scaler.md ================================================ +++ title = "Selenium Grid Scaler" availability = "v2.4+" maintainer = "Volvo Cars" description = "Scales Selenium browser nodes based on number of requests waiting in session queue" go_file = "selenium_grid_scaler" +++ ### Trigger Specification This specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid. The scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid. The below is an example trigger configuration for chrome node. ```yaml triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication. browserName: 'chrome' # Required browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid. unsafeSsl : 'true' # Optional activationThreshold: 5 # Optional ``` **Parameter list:** - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. - `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. - `sessionBrowserName` - Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional) - `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional) - `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional) - `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) ### Example Here is a full example of scaled object definition using Selenium Grid trigger: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' ``` The above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser. Similarly for Firefox ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-firefox-scaledobject namespace: keda labels: deploymentName: selenium-firefox-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-firefox-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'firefox' ``` Similarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-edge-scaledobject namespace: keda labels: deploymentName: selenium-edge-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-edge-node triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'MicrosoftEdge' sessionBrowserName: 'msedge' ``` If you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-91-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-91 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-91 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '91.0' ``` ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-90-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node-90 spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node-90 triggers: - type: selenium-grid metadata: url: 'http://selenium-hub:4444/graphql' browserName: 'chrome' browserVersion: '90.0' ``` ### Authentication Parameters It is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure. - `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info. ```yaml apiVersion: v1 kind: Secret metadata: name: selenium-grid-secret namespace: keda type: Opaque data: graphql-url: base64 encoded value of GraphQL URL --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-trigger-auth-selenium-grid-secret namespace: keda spec: secretTargetRef: - parameter: url name: selenium-grid-secret key: graphql-url --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: selenium-grid-chrome-scaledobject namespace: keda labels: deploymentName: selenium-chrome-node spec: maxReplicaCount: 8 scaleTargetRef: name: selenium-chrome-node triggers: - type: selenium-grid metadata: browserName: 'chrome' authenticationRef: name: keda-trigger-auth-selenium-grid-secret ``` ================================================ FILE: content/docs/2.9/scalers/solace-pub-sub.md ================================================ +++ title = "Solace PubSub+ Event Broker" availability = "2.4+" maintainer = "Community" description = "Scale applications based on Solace PubSub+ Event Broker Queues" go_file = "solace_scaler" +++ ### Trigger Specification This specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue. ```yaml triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://solace_broker:8080 messageVpn: message-vpn queueName: queue_name messageCountTarget: '100' messageSpoolUsageTarget: '100' ### Megabytes (MB) activationMessageCountTarget: '100' activationMessageSpoolUsageTarget: '100' ### Megabytes (MB) username: semp-user password: semp-pwd usernameFromEnv: ENV_VAR_USER passwordFromEnv: ENV_VAR_PWD ``` **Parameter list:** - `solaceSempBaseURL` - Solace SEMP Endpoint in format: `://:`. - `messageVpn` - Message VPN hosted on the Solace broker. - `queueName` - Message Queue to be monitored. - `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica. - `activationMessageCountTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica. - `activationMessageSpoolUsageTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional) - `username` - User account with access to Solace SEMP RESTful endpoint. - `password` - Password for the user account. - `usernameFromEnv` - Environment variable set with SEMP user account. - `passwordFromEnv` - Environment variable set with password for the user account. **Parameter Requirements:** - Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName` - **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior) - The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`. ### Authentication Parameters You can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint. **Username and Password based authentication:** - `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. - `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint. ### Example The objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace. ```yaml apiVersion: v1 kind: Secret metadata: name: solace-secret namespace: solace labels: app: solace-consumer type: Opaque data: SEMP_USER: YWRtaW4= SEMP_PASSWORD: S2VkYUxhYkFkbWluUHdkMQ== --- apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: solace-scaled-object namespace: solace spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: solace-consumer pollingInterval: 20 cooldownPeriod: 60 minReplicaCount: 0 maxReplicaCount: 10 triggers: - type: solace-event-queue metadata: solaceSempBaseURL: http://broker-pubsubplus.solace.svc.cluster.local:8080 messageVpn: test_vpn queueName: SCALED_CONSUMER_QUEUE1 messageCountTarget: '50' messageSpoolUsageTarget: '100000' authenticationRef: name: solace-trigger-auth --- apiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: solace-trigger-auth namespace: solace spec: secretTargetRef: - parameter: username name: solace-secret key: SEMP_USER - parameter: password name: solace-secret key: SEMP_PASSWORD ``` ================================================ FILE: content/docs/2.9/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "How to address commonly encountered KEDA issues" +++ {{< troubleshooting >}} ================================================ FILE: content/docs/_index.md ================================================ --- build: render: false --- ================================================ FILE: content/enterprise.md ================================================ +++ title = "Enterprise" description = "Enterprise and commercially supported solutions based on KEDA" +++ {{< enterprise >}} ================================================ FILE: content/http-add-on/0.14/_index.md ================================================ +++ title = "KEDA HTTP Add-on" description = "HTTP-based autoscaling for Kubernetes workloads, including scale-to-zero" weight = 1 +++ The KEDA HTTP Add-on enables automatic scaling of HTTP workloads on Kubernetes based on incoming traffic, including scaling to and from zero replicas. It extends [KEDA](https://keda.sh) with the infrastructure needed to intercept HTTP requests, count them, and report metrics that drive scaling decisions. ## How It Works The HTTP Add-on deploys three components into your cluster: - An **interceptor** that sits in front of your application as a reverse proxy, routing requests and tracking concurrency. - A **scaler** that aggregates request metrics from the interceptor and reports them to KEDA. - An **operator** that manages the lifecycle of scaling resources. You create an `InterceptorRoute` to define how traffic reaches your service and a KEDA `ScaledObject` to control scaling behavior. The interceptor handles requests while KEDA scales your workload up and down based on demand. ## Get Started If you are new to the HTTP Add-on, follow the [Getting Started guide](getting-started/) to deploy and scale your first HTTP application. ## Upgrading from a Previous Version v0.14.0 introduces the `InterceptorRoute` (v1beta1) API, which replaces `HTTPScaledObject` (v1alpha1). If you have existing `HTTPScaledObject` resources, see [Migrate from HTTPScaledObject to InterceptorRoute](operations/migrate-httpscaledobject-to-interceptorroute/). ## Documentation Sections - **[Getting Started](getting-started/)** — Tutorial: install the add-on and scale your first app end-to-end. - **[Concepts](concepts/)** — Understand the architecture, scaling mechanics, and routing model. - **[User Guide](user-guide/)** — Configure autoscaling, routing, and timeouts for your HTTP applications. - **[Operations](operations/)** — Install, configure, and manage the HTTP Add-on infrastructure. - **[Reference](reference/)** — API specifications, Helm chart values, environment variables, and metrics. ## Getting Help - [Kubernetes Slack](https://kubernetes.slack.com/archives/CKZJ36A5D) — `#keda` channel ([join here](https://slack.k8s.io)) - [GitHub Issues](https://github.com/kedacore/http-add-on/issues) — Bug reports and feature requests - [GitHub Discussions](https://github.com/kedacore/http-add-on/discussions) — Questions and general conversation ## Contributing Contributions to the HTTP Add-on are welcome. See the [contributing guide](https://github.com/kedacore/http-add-on/blob/main/CONTRIBUTING.md) in the source repository for development setup, commit conventions, and PR guidelines. ================================================ FILE: content/http-add-on/0.14/concepts/_index.md ================================================ +++ title = "Concepts" description = "Architecture, scaling mechanics, and routing model of the HTTP Add-on" weight = 200 +++ Learn how the HTTP Add-on works before configuring it. - **[Architecture](architecture/)** — The three components, how they interact, and the request flow. - **[Routing](routing/)** — Host, path, and header matching with priority rules. - **[Scaling](scaling/)** — Scaling metrics, scale-to-zero, and cold-start behavior. ================================================ FILE: content/http-add-on/0.14/concepts/architecture.md ================================================ +++ title = "Architecture" description = "The three components of the HTTP Add-on, their responsibilities, and how they interact to scale HTTP workloads" +++ ## The Problem: HTTP Has No Queue Event-driven scalers such as those for Kafka or RabbitMQ can read the number of pending messages directly from a broker. HTTP has no equivalent concept: a request arrives, gets processed, and is gone. There is nothing for an autoscaler to query. The HTTP Add-on solves this by placing dedicated infrastructure in the request path. An interceptor proxy sits in front of your application, counts requests as they flow through, and holds requests during cold starts while backends scale up. A scaler component aggregates those counts into metrics that [KEDA](https://keda.sh/docs/) can use to drive the Horizontal Pod Autoscaler (HPA). ## KEDA Core Concepts Before diving into the HTTP Add-on components, a few KEDA primitives are relevant: - **ScaledObject** — A KEDA custom resource that binds a workload (Deployment, StatefulSet, etc.) to one or more scaling triggers. KEDA watches ScaledObjects and configures the Kubernetes HPA accordingly. See the [KEDA ScaledObject documentation](https://keda.sh/docs/latest/concepts/scaling-deployments/). - **External scaler** — A gRPC service that KEDA calls to fetch custom metrics. The HTTP Add-on's scaler component implements this interface. See the [KEDA external scalers documentation](https://keda.sh/docs/latest/concepts/external-scalers/). - **HPA** — The Kubernetes Horizontal Pod Autoscaler. KEDA creates and manages an HPA for each ScaledObject. The HPA adjusts replica counts based on the metrics KEDA feeds it. ## Component Overview The HTTP Add-on consists of three components deployed into the cluster: ### Interceptor The interceptor is a reverse proxy that sits in the request path between the ingress layer and the backend service. It performs three functions: 1. **Routing** — Matches incoming requests to backend services based on hostname, path prefix, and headers. See [Routing](../routing/) for the matching model. 2. **Counting** — Tracks the number of concurrent (in-flight) requests and total request counts per route. These counters are the raw data the scaler uses to compute scaling metrics. 3. **Buffering** — During cold starts (when a backend has zero replicas), the interceptor holds the request open while waiting for the backend to become ready. Once at least one pod is available, the request is forwarded. If the backend does not become ready within the readiness timeout, the interceptor returns an error or routes to a fallback service if configured. The interceptor forwards requests to the backend's Kubernetes Service, relying on standard Kubernetes service load balancing for distribution across pods. The interceptor deployment is itself auto-scaled by KEDA via a ScaledObject created by the Helm chart. ### Scaler The scaler is the bridge between the interceptor's in-memory counters and KEDA's scaling decisions. It implements the KEDA external scaler interface. The scaler periodically polls all interceptor pods to fetch per-route request counts. It aggregates concurrency across pods for each route and computes request rate from the total request counters. When KEDA queries the scaler, it returns these aggregated metrics so KEDA can adjust replica counts. See [Scaling](../scaling/) for details on how these metrics drive scaling decisions. ### Operator The operator is a Kubernetes controller manager that reconciles HTTP Add-on custom resources: - **InterceptorRoute** (`http.keda.sh/v1beta1`) — Defines routing rules, scaling metrics, target service, and timeout/cold-start configuration in a single resource. Users pair it with a KEDA ScaledObject they create and manage. - **HTTPScaledObject** (`http.keda.sh/v1alpha1`, deprecated) — Combines routing, scaling, and ScaledObject management in one resource. The operator automatically creates the corresponding ScaledObject. See the [InterceptorRoute reference](../../reference/interceptorroute/) for the full API specification. ## Request Flow ``` +---------+ +-------------+ +---------+ | Ingress +---->| Interceptor +---->| Backend | +---------+ +------+------+ +---------+ | poll metrics | +------+------+ | Scaler | +------+------+ | report metrics | +------+------+ | KEDA Core | +------+------+ | adjust replicas | +------+------+ | HPA | +-------------+ ``` 1. External traffic enters the cluster through an ingress controller (or Gateway API) and is routed to the interceptor service. 2. The interceptor matches the request to a route, counts it, and forwards the request to the backend. If the backend has zero replicas, the interceptor holds the request until a pod becomes ready. 3. When the backend responds, the interceptor returns the response to the client. 4. The scaler polls the interceptor to aggregate request counts and compute rate metrics. 5. KEDA queries the scaler for current metrics and determines the desired replica count. 6. KEDA configures the HPA, which adjusts the backend's replica count. ## What's Next - [Scaling](../scaling/) — How scaling decisions are made, including scale-to-zero and cold starts. - [Routing](../routing/) — How requests are matched to InterceptorRoutes. - [Install the HTTP Add-on](../../operations/installation/) — Install the HTTP Add-on via Helm. ================================================ FILE: content/http-add-on/0.14/concepts/routing.md ================================================ +++ title = "Routing" description = "Interceptor request matching using hostname, path, and header rules" +++ The interceptor maintains an in-memory routing table that maps incoming HTTP requests to InterceptorRoute resources. Each InterceptorRoute defines one or more routing rules, and each rule can match on three dimensions: hostname, path prefix, and headers. ## Routing Rules An InterceptorRoute contains a list of routing rules in `spec.rules`. Each rule specifies hosts, paths, and headers to match. A request that matches any rule in the InterceptorRoute is forwarded to that InterceptorRoute's target service. When a rule omits hosts, it matches any hostname (catch-all). When it omits paths, it matches the root path `/`. When it omits headers, no header matching is performed. ## Matching Dimensions ### Hostname Matching The interceptor matches the `Host` header of the request against the hostnames declared in routing rules. Three kinds of hostname values are supported: - **Exact hostnames** (`api.example.com`) - Match the request hostname exactly. - Exact matches take priority over all wildcard forms. - **Wildcard hostnames** (`*.example.com`) - The `*` replaces the first DNS label. - A wildcard matches any hostname that ends with the remaining labels: `*.example.com` matches `foo.example.com` and `foo.bar.example.com` (multi-level). - More specific wildcards take priority: `*.bar.example.com` wins over `*.example.com` for a request to `api.bar.example.com`. - **Catch-all** (`*` or omitted) - Matches any hostname. - This is the lowest priority. The interceptor evaluates hostnames in priority order: exact match first, then wildcards from most specific to least specific, then catch-all. ### Path Matching The interceptor uses longest-prefix matching on the request path. All paths are normalized by trimming leading and trailing slashes. When multiple routes match on hostname, the route with the longest matching path prefix wins. For example, a request to `/api/v1/users` matches a rule with path `/api/v1` over a rule with path `/api`. The routing table uses a radix tree internally, which makes longest-prefix lookups efficient regardless of the number of routes. ### Header Matching Header matching adds a further dimension of specificity. A routing rule can declare one or more headers that the request must carry: - **Exact value match** — The rule specifies both a header name and a value (e.g., `name: X-Route, value: canary`). The request must contain the header with that exact value. - **Presence-only match** — The rule specifies a header name without a value (e.g., `name: X-Route`). The request must contain the header, but any value is accepted. All headers in a single rule must match for the rule to apply (AND semantics). If a rule declares no headers, it matches regardless of what headers the request carries. ## Priority Order When multiple InterceptorRoutes match a request, the interceptor selects the most specific one using the following tiebreaking order: 1. **Most specific hostname** — Exact hostname wins over wildcard, which wins over catch-all. Among wildcards, more specific patterns (more labels) take priority. 2. **Longest path prefix** — A longer matching prefix wins. 3. **Most specific headers** — Routes with more header matchers take priority. Among routes with the same number of headers, routes with more exact-value matches (as opposed to presence-only matches) take priority. 4. **Oldest creation timestamp** — The InterceptorRoute created first wins. 5. **Lexicographic namespace/name** — Final tiebreaker using the resource's namespace and name in descending lexicographic order. ### Example Consider three InterceptorRoutes: | Route | Host | Path | Headers | | ----- | ----------------- | --------- | -------------- | | A | `api.example.com` | `/api` | (none) | | B | `*.example.com` | `/api/v1` | `X-Version: 2` | | C | `api.example.com` | `/api/v1` | (none) | A request to `api.example.com` with path `/api/v1/users` and header `X-Version: 2`: - Route A matches (exact host, path `/api` is a prefix). - Route B matches (wildcard host, path `/api/v1` is a prefix, header matches). - Route C matches (exact host, path `/api/v1` is a prefix). Applying the priority rules: Routes A and C have an exact hostname, which beats B's wildcard. Between A and C, C has the longer path prefix (`/api/v1` vs `/api`). **Route C wins.** ## Multiple Rules per InterceptorRoute A single InterceptorRoute can contain multiple routing rules. Each rule independently specifies its own hosts, paths, and headers. A request that matches any one of these rules is routed to the InterceptorRoute's target service. This allows a single InterceptorRoute to serve traffic for multiple hostnames or path patterns without requiring separate resources for each. ## What's Next - [Configure Routing Rules](../../user-guide/configure-routing/) — YAML examples for host, path, and header matching. - [InterceptorRoute Reference](../../reference/interceptorroute/) — Complete field definitions for routing rules. ================================================ FILE: content/http-add-on/0.14/concepts/scaling.md ================================================ +++ title = "Scaling" description = "HTTP Add-on scaling decisions, including metrics, scale-to-zero, and cold-start behavior" +++ The HTTP Add-on provides two scaling metrics: concurrency and request rate. KEDA uses these metrics to adjust the replica count of backend workloads through the Horizontal Pod Autoscaler (HPA). ## Scaling Metrics ### Concurrency Concurrency measures the number of in-flight requests at any instant for a given route. The interceptor increments a counter when a request arrives and decrements it when the response completes. ### Request Rate Request rate measures the number of requests per second, averaged over a sliding time window. The windowed averaging smooths out short bursts and provides a stable signal for scaling. The default configuration is: - **Window**: 1 minute - **Granularity**: 1 second ### Using Both Metrics When an InterceptorRoute specifies both concurrency and request rate targets, KEDA evaluates each metric independently and scales to whichever demands more replicas. This is standard KEDA/HPA behavior: the metric requiring the highest replica count wins. ## The Scaling Formula The desired replica count for a single metric follows the standard HPA formula: ``` desiredReplicas = ceil(currentMetricValue / targetValue) ``` For example, with a concurrency target of 100 and a current concurrency of 250, the desired count is `ceil(250 / 100) = 3`. This calculation happens within the Kubernetes HPA based on the metrics and targets that KEDA provides. ## How Metrics Flow 1. A request arrives at the interceptor, which counts it. 2. The scaler periodically polls all interceptor pods to collect per-route request counts. 3. The scaler aggregates concurrency across pods and computes request rate for each route. 4. KEDA queries the scaler for current metrics and determines the desired replica count. 5. KEDA configures the HPA, which adjusts the backend's replica count. ## Scale-to-Zero When all metrics for a route drop to zero and the ScaledObject's `cooldownPeriod` expires, KEDA scales the backend workload to zero replicas. The `cooldownPeriod` is a field on the KEDA ScaledObject (not the InterceptorRoute). It defines how long all metrics must remain at zero before KEDA scales the workload down to zero. ## Cold Starts When a request arrives for a backend that has been scaled to zero, the interceptor holds the request while KEDA scales the backend up. The sequence is: 1. The interceptor matches the request to a route and counts it. 2. The scaler detects incoming traffic and reports the workload as active to KEDA. 3. KEDA scales the backend workload from 0 to 1 or more replicas. 4. Once at least one backend pod is ready, the interceptor forwards the held request. 5. The response flows back through the interceptor to the client. If the backend does not become ready within the readiness timeout, the interceptor either routes to a fallback service (if configured) or returns an error. See [Configure Cold-Start Behavior](../../user-guide/configure-cold-start/) for fallback configuration and [Configure Timeouts](../../user-guide/configure-timeouts/) for timeout settings. ## What's Next - [Configure Scaling Metrics](../../user-guide/configure-scaling/) — Choose between concurrency and request rate, and tune target values. - [Configure Timeouts](../../user-guide/configure-timeouts/) — Set readiness timeouts per route. - [Configure Cold-Start Behavior](../../user-guide/configure-cold-start/) — Fallback services and cold-start response headers. - [Architecture](../architecture/) — Overview of the three components and how they interact. ================================================ FILE: content/http-add-on/0.14/getting-started/_index.md ================================================ +++ title = "Getting Started" description = "Sample HTTP application deployment and autoscaling with the KEDA HTTP Add-on" weight = 100 +++ In this tutorial, we will install the KEDA HTTP Add-on and use it to autoscale an HTTP application based on incoming traffic — including scaling to zero when idle. By the end, we will have: - A sample HTTP application running in our cluster - The HTTP Add-on intercepting and counting requests - KEDA scaling the application up under load and back to zero when traffic stops ## Prerequisites Before we begin, we need: - A Kubernetes cluster (kind, minikube, or a cloud provider) - `kubectl` configured to access the cluster - [Helm 3](https://helm.sh/docs/intro/install/) installed - KEDA core installed: ```shell helm install keda kedacore/keda --namespace keda --create-namespace ``` See the [KEDA deployment docs](https://keda.sh/docs/deploy/) for other installation methods. ## Step 1: Add the KEDA Helm Repository If we have not already added the KEDA Helm repository, we add it now and update our local chart index: ```shell helm repo add kedacore https://kedacore.github.io/charts helm repo update ``` ## Step 2: Install the HTTP Add-on We install the HTTP Add-on into the same `keda` namespace where KEDA core is running: ```shell helm install http-add-on kedacore/keda-add-ons-http --namespace keda ``` We verify that all components are running: ```shell kubectl get pods -n keda ``` We will see pods for the operator, interceptor, and scaler — all with a `Running` status: ``` NAME READY STATUS RESTARTS AGE keda-add-ons-http-interceptor-... 1/1 Running 0 30s keda-add-ons-http-operator-... 1/1 Running 0 30s keda-add-ons-http-scaler-... 1/1 Running 0 30s keda-admission-webhooks-... 1/1 Running 0 2m keda-operator-... 1/1 Running 0 2m keda-operator-metrics-apiserver-... 1/1 Running 0 2m ``` ## Step 3: Deploy a Sample Application We create a namespace and deploy a sample HTTP application using [traefik/whoami](https://github.com/traefik/whoami), a lightweight HTTP server that responds with request metadata. ```shell kubectl create namespace demo ``` We deploy a Deployment and Service: ```shell kubectl apply -f - < /dev/null; done ``` After the burst finishes, we check the deployment: ```shell kubectl get deployment sample-app -n demo ``` We will see the replica count has increased: ``` NAME READY UP-TO-DATE AVAILABLE AGE sample-app 2/2 2 2 5m ``` ## Step 8: Observe Scale to Zero After the burst ends and the cooldown period passes (30 seconds, as configured in our ScaledObject), KEDA scales the deployment back to 0. We can watch this happen: ```shell kubectl get deployment sample-app -n demo -w ``` We will see replicas decrease to 0: ``` NAME READY UP-TO-DATE AVAILABLE AGE sample-app 2/2 2 2 5m sample-app 1/1 1 1 6m sample-app 0/0 0 0 7m ``` ## Step 9: Clean Up To remove the sample application and all its resources: ```shell kubectl delete namespace demo ``` ## What's Next - [Architecture](../concepts/architecture/) — Understand how the interceptor, scaler, and operator work together. - [Autoscale an App](../user-guide/autoscale-an-app/) — Apply this pattern to your own services. - [Configure Ingress](../user-guide/configure-ingress/) — Set up Gateway API or Ingress for production traffic. - [Configure Scaling Metrics](../user-guide/configure-scaling/) — Tune concurrency targets or switch to request-rate scaling. ## Getting Help - [Kubernetes Slack](https://kubernetes.slack.com/archives/CKZJ36A5D) — `#keda` channel ([join here](https://slack.k8s.io)) - [GitHub Issues](https://github.com/kedacore/http-add-on/issues) — Bug reports and feature requests - [GitHub Discussions](https://github.com/kedacore/http-add-on/discussions) — Questions and general conversation ================================================ FILE: content/http-add-on/0.14/operations/_index.md ================================================ +++ title = "Operations" description = "HTTP Add-on infrastructure installation, configuration, and management" weight = 400 +++ Guides for platform administrators installing and managing the HTTP Add-on. - **[Configure the Interceptor](configure-interceptor/)** — Timeouts, connection tuning, and scaling. - **[Configure Observability](configure-observability/)** — Prometheus metrics, OpenTelemetry tracing, and request logging. - **[Configure TLS](configure-tls/)** — TLS termination, certificates, and cipher suites. - **[Install the HTTP Add-on](installation/)** — Install, upgrade, and uninstall via Helm. - **[Migrate from HTTPScaledObject to InterceptorRoute](migrate-httpscaledobject-to-interceptorroute/)** — Upgrade existing resources to the v1beta1 API. - **[Troubleshooting](troubleshooting/)** — Debug request routing, inspect queue state, and profile performance. ================================================ FILE: content/http-add-on/0.14/operations/configure-interceptor.md ================================================ +++ title = "Configure the Interceptor" description = "Timeout, connection, and scaling configuration for the interceptor proxy" +++ The interceptor is the reverse proxy that sits in front of your application. This page covers infrastructure-level settings configured via Helm values and environment variables. ## Timeouts Global timeouts apply to all routes and serve as cluster-wide defaults. Application developers can override these values per route on the `InterceptorRoute` — see [Configure Timeouts](../../user-guide/configure-timeouts/). Set global defaults via Helm values: ```shell helm install http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.requestTimeout=30s \ --set interceptor.responseHeaderTimeout=15s \ --set interceptor.readinessTimeout=20s ``` | Timeout | Helm value | Env var | Default | | --------------- | ----------------------------------- | ----------------------------------- | ------------------------------------------------------------------ | | Request | `interceptor.requestTimeout` | `KEDA_HTTP_REQUEST_TIMEOUT` | `0s` (disabled — no total deadline) | | Response header | `interceptor.responseHeaderTimeout` | `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | `300s` | | Readiness | `interceptor.readinessTimeout` | `KEDA_HTTP_READINESS_TIMEOUT` | `0s` (disabled — readiness wait is bounded by the request timeout) | | Connect | `interceptor.tcpConnectTimeout` | `KEDA_HTTP_CONNECT_TIMEOUT` | `500ms` | ## Cold-start response header The interceptor adds an `X-KEDA-HTTP-Cold-Start` response header to indicate whether a cold start occurred. This header is enabled by default. To disable it: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.extraEnvs.KEDA_HTTP_ENABLE_COLD_START_HEADER=false ``` ## Connection tuning Configure the interceptor's connection pool for backend services: | Helm value | Env var | Default | Description | | --------------------------------- | ----------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- | | `interceptor.maxIdleConns` | `KEDA_HTTP_MAX_IDLE_CONNS` | `1000` | Maximum idle connections across all backend services. Increase this if you proxy to many backends. | | `interceptor.maxIdleConnsPerHost` | `KEDA_HTTP_MAX_IDLE_CONNS_PER_HOST` | `200` | Maximum idle connections per backend. Increase this if you observe frequent connection establishments under load. | ## Interceptor scaling The interceptor itself is auto-scaled by KEDA via a `ScaledObject` created by the Helm chart. Configure the interceptor's scaling bounds: | Helm value | Default | Description | | -------------------------- | ------- | ----------------------------- | | `interceptor.replicas.min` | `3` | Minimum interceptor replicas. | | `interceptor.replicas.max` | `50` | Maximum interceptor replicas. | ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.replicas.min= \ --set interceptor.replicas.max= ``` ## What's Next - [Configure TLS](../configure-tls/) — TLS termination, certificates, and cipher suites. - [Configure Observability](../configure-observability/) — Prometheus metrics, OpenTelemetry tracing, and request logging. - [Environment Variables Reference](../../reference/environment-variables/) — all environment variables for each component. ================================================ FILE: content/http-add-on/0.14/operations/configure-observability.md ================================================ +++ title = "Configure Observability" description = "Prometheus metrics, OpenTelemetry tracing, and request logging configuration for the interceptor" +++ The interceptor exposes metrics and tracing data to help monitor HTTP traffic and scaling behavior. All observability settings are configured via environment variables, set through the `interceptor.extraEnvs` Helm value. ## Prometheus metrics The interceptor exposes Prometheus metrics at `/metrics` on port `2223`. This is enabled by default. | Env var | Default | Description | | ---------------------------- | ------- | ----------------------------------------- | | `OTEL_PROM_EXPORTER_ENABLED` | `true` | Enable the Prometheus metrics endpoint. | | `OTEL_PROM_EXPORTER_PORT` | `2223` | Port for the Prometheus metrics endpoint. | See [Metrics Reference](../../reference/metrics/) for the full list of metrics and labels. ## OpenTelemetry tracing Enable distributed tracing via OTLP: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_TRACES_ENABLED=true \ --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=grpc \ --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_ENDPOINT=http://:4317 ``` The interceptor uses W3C TraceContext and Baggage propagation. | Env var | Default | Description | | ------------------------------------ | --------- | ------------------------------------------------------- | | `OTEL_EXPORTER_OTLP_TRACES_ENABLED` | `false` | Enable OTLP trace export. | | `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` | `console` | Exporter protocol (`grpc`, `http/protobuf`, `console`). | | `OTEL_EXPORTER_OTLP_ENDPOINT` | — | Collector endpoint URL. | | `OTEL_EXPORTER_OTLP_HEADERS` | — | Authentication headers (e.g., `api-key=`). | | `OTEL_EXPORTER_OTLP_TRACES_TIMEOUT` | `10s` | Timeout for trace export requests. | ## OpenTelemetry metrics Enable OTLP metrics export alongside or instead of Prometheus: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_METRICS_ENABLED=true \ --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_ENDPOINT=http://:4317 ``` | Env var | Default | Description | | ------------------------------------ | ------- | --------------------------------------------------- | | `OTEL_EXPORTER_OTLP_METRICS_ENABLED` | `false` | Enable OTLP metrics export. | | `OTEL_EXPORTER_OTLP_ENDPOINT` | — | Collector endpoint URL (shared with traces if set). | | `OTEL_EXPORTER_OTLP_HEADERS` | — | Authentication headers (shared with traces if set). | | `OTEL_METRIC_EXPORT_INTERVAL` | `60s` | Interval between periodic metric exports. | ## Request logging Enable Combined Log Format request logging: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.extraEnvs.KEDA_HTTP_LOG_REQUESTS=true ``` ## What's Next - [Metrics Reference](../../reference/metrics/) — detailed Prometheus metric definitions. - [Environment Variables Reference](../../reference/environment-variables/) — all observability-related environment variables. ================================================ FILE: content/http-add-on/0.14/operations/configure-tls.md ================================================ +++ title = "Configure TLS" description = "TLS termination, certificates, cipher suites, and SNI configuration for the interceptor proxy" +++ > **Note:** This page has not been fully verified against the current implementation. > Configuration values, environment variable names, or default values may be inaccurate or incomplete. > If you find an issue, please [open a GitHub issue](https://github.com/kedacore/keda-docs/issues/new) or submit a pull request. The interceptor can terminate TLS for incoming connections. All TLS settings are configured via Helm values and environment variables. ## Enable TLS termination Enable TLS on the interceptor proxy: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.tls.enabled=true \ --set interceptor.tls.certSecret= ``` The interceptor loads TLS certificates from a Kubernetes Secret mounted at `/certs`. The Secret must contain `tls.crt` and `tls.key` entries. ## TLS settings | Helm value | Env var | Default | Description | | ---------------------------------- | --------------------------------------- | ------------------------------ | ------------------------------------------------------------------------ | | `interceptor.tls.enabled` | `KEDA_HTTP_PROXY_TLS_ENABLED` | `false` | Enable TLS on the proxy. | | `interceptor.tls.port` | `KEDA_HTTP_PROXY_TLS_PORT` | `8443` | Port the TLS proxy listens on. | | `interceptor.tls.certSecret` | — | `keda-tls-certs` | Name of the Kubernetes Secret containing the TLS certificate and key. | | `interceptor.tls.certPath` | `KEDA_HTTP_PROXY_TLS_CERT_PATH` | `/certs/tls.crt` | Path to the certificate file. | | `interceptor.tls.keyPath` | `KEDA_HTTP_PROXY_TLS_KEY_PATH` | `/certs/tls.key` | Path to the private key file. | | `interceptor.tls.minVersion` | `KEDA_HTTP_PROXY_TLS_MIN_VERSION` | Go default (TLS 1.2) | Minimum TLS version (`"1.2"` or `"1.3"`). | | `interceptor.tls.maxVersion` | `KEDA_HTTP_PROXY_TLS_MAX_VERSION` | Go default (highest supported) | Maximum TLS version (`"1.2"` or `"1.3"`). | | `interceptor.tls.cipherSuites` | `KEDA_HTTP_PROXY_TLS_CIPHER_SUITES` | Go defaults | Comma-separated list of cipher suite names. | | `interceptor.tls.curvePreferences` | `KEDA_HTTP_PROXY_TLS_CURVE_PREFERENCES` | Go defaults | Comma-separated list of elliptic curve names (e.g., `X25519,CurveP256`). | | `interceptor.tls.skipVerify` | `KEDA_HTTP_PROXY_TLS_SKIP_VERIFY` | `false` | Skip TLS verification for upstream (backend) connections. | ## SNI-based certificate selection The interceptor supports SNI-based certificate selection when multiple certificate/key pairs are loaded via the `KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHS` environment variable. Set this to a comma-separated list of paths containing additional certificate/key pairs. ## What's Next - [Environment Variables Reference](../../reference/environment-variables/) — all TLS-related environment variables. ================================================ FILE: content/http-add-on/0.14/operations/installation.md ================================================ +++ title = "Install the HTTP Add-on" description = "HTTP Add-on installation, upgrade, and removal via Helm" weight = 1 +++ ## Prerequisites Before installing the HTTP Add-on, ensure you have: - A Kubernetes cluster (tested against the three most recent minor versions) - [Helm 3](https://helm.sh/docs/intro/install/) - KEDA core installed ([deployment guide](https://keda.sh/docs/deploy/)) If you have not installed KEDA yet, run: ```shell helm repo add kedacore https://kedacore.github.io/charts helm repo update helm install keda kedacore/keda --namespace keda --create-namespace ``` ## Install 1. Add the KEDA Helm repository (if you have not already): ```shell helm repo add kedacore https://kedacore.github.io/charts helm repo update ``` 2. Install the HTTP Add-on into the same namespace as KEDA: ```shell helm install http-add-on kedacore/keda-add-ons-http --namespace keda ``` 3. Verify the installation: ```shell kubectl get pods -n keda ``` You should see pods for the operator, interceptor, and scaler components in a `Running` state. ### Helm Values to Consider The following values are commonly configured at install time. Pass them with `--set` or in a values file (`-f values.yaml`). | Value | Description | Default | | -------------------------- | --------------------------------------------------------------------------------- | ------- | | `interceptor.replicas.min` | Minimum number of interceptor replicas | `3` | | `interceptor.replicas.max` | Maximum number of interceptor replicas | `50` | | `operator.watchNamespace` | Restrict the operator to a single namespace (empty string watches all namespaces) | `""` | For the full list of configuration options, see the [http-add-on chart](https://github.com/kedacore/charts/tree/main/http-add-on#configuration). ## Upgrade To upgrade to a newer version of the HTTP Add-on: ```shell helm repo update helm upgrade http-add-on kedacore/keda-add-ons-http --namespace keda ``` The CRDs are included as Helm templates (not in the `crds/` directory), so they are updated automatically during `helm upgrade`. ## Uninstall 1. Remove the HTTP Add-on Helm release: ```shell helm uninstall http-add-on --namespace keda ``` 2. CRDs are **not** automatically removed on uninstall. To remove them manually: ```shell kubectl delete crd httpscaledobjects.http.keda.sh interceptorroutes.http.keda.sh ``` > **Warning:** Deleting the CRDs removes all `HTTPScaledObject` and `InterceptorRoute` resources in the cluster. Make sure you no longer need them before proceeding. ## Namespace-Scoped Installation By default, the operator watches all namespaces for `HTTPScaledObject` and `InterceptorRoute` resources. To restrict the operator to a single namespace: ```shell helm install http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set operator.watchNamespace= ``` For the full list of configuration options, see the [http-add-on chart](https://github.com/kedacore/charts/tree/main/http-add-on#configuration). ## What's Next - [Autoscale an App](../../user-guide/autoscale-an-app/) — Create a ScaledObject and InterceptorRoute for your service. - [Configure the Interceptor](../configure-interceptor/) — Timeouts, connection tuning, and scaling. ================================================ FILE: content/http-add-on/0.14/operations/migrate-httpscaledobject-to-interceptorroute.md ================================================ +++ title = "Migrate from HTTPScaledObject to InterceptorRoute" description = "How to migrate existing HTTPScaledObject resources to the InterceptorRoute API" +++ This guide shows you how to migrate existing `HTTPScaledObject` (v1alpha1) resources to the `InterceptorRoute` (v1beta1) API. ## Prerequisites - KEDA HTTP Add-on v0.14.0 or later deployed on the cluster - `kubectl` access to the cluster - Existing `HTTPScaledObject` resources to migrate ## What changed The `InterceptorRoute` API replaces `HTTPScaledObject` with a cleaner separation of concerns. - **Manual ScaledObject management:** The `InterceptorRoute` controller no longer creates a KEDA `ScaledObject` for you. You create and manage it yourself, with access to all supported KEDA ScaledObject fields. - **Multiple routing rules:** A new `rules[]` structure lets you define multiple routing rules on a single resource, each with its own hosts, paths, and headers. - **Target reference for routing only:** The target reference contains only `service` and `port`/`portName`. Workload fields (`name`, `apiVersion`, `kind`) move to the `ScaledObject` where they belong. - **Flexible scaling metrics:** Concurrency and request rate can be used independently or together. When both are set, KEDA scales based on whichever metric demands more replicas. - **Granular timeouts:** A new `request` timeout controls the full request lifecycle. `conditionWait` is renamed to `readiness` for clarity. - **`targetValue` is required:** On `HTTPScaledObject`, `targetValue` defaulted to `100` when omitted. On `InterceptorRoute`, `targetValue` must be set explicitly. If your `HTTPScaledObject` relied on the default, add `targetValue: 100` (or your preferred value) when migrating. - **Scaling fields move to ScaledObject:** `replicas`, `targetPendingRequests`, `scaledownPeriod`, and `initialCooldownPeriod` are configured on the KEDA `ScaledObject` directly. ## Convert an HTTPScaledObject to an InterceptorRoute The migration is a direct field-by-field conversion. The [Apply the migration without downtime](#apply-the-migration-without-downtime) section below shows how to perform the switchover without interrupting traffic. ### Before: HTTPScaledObject ```yaml apiVersion: http.keda.sh/v1alpha1 kind: HTTPScaledObject metadata: name: my-app namespace: default spec: hosts: - app.example.com pathPrefixes: - /api - /health headers: - name: X-Custom-Header value: "my-value" scaleTargetRef: name: my-app kind: Deployment apiVersion: apps/v1 service: my-app-svc port: 8080 coldStartTimeoutFailoverRef: service: fallback-svc port: 8080 timeoutSeconds: 45 replicas: min: 0 max: 10 scalingMetric: concurrency: targetValue: 50 timeouts: conditionWait: 30s responseHeader: 10s scaledownPeriod: 120 ``` ### After: InterceptorRoute and ScaledObject The single `HTTPScaledObject` becomes two resources: an `InterceptorRoute` for routing and an independently managed `ScaledObject` for scaling. **InterceptorRoute:** ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app namespace: default spec: target: service: my-app-svc port: 8080 coldStart: fallback: service: fallback-svc port: 8080 rules: - hosts: - app.example.com paths: - value: /api - value: /health headers: - name: X-Custom-Header value: "my-value" scalingMetric: concurrency: targetValue: 50 timeouts: readiness: 45s responseHeader: 10s ``` **ScaledObject:** ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: my-app namespace: default spec: scaleTargetRef: name: my-app kind: Deployment apiVersion: apps/v1 minReplicaCount: 0 maxReplicaCount: 10 cooldownPeriod: 120 triggers: - type: external-push metadata: scalerAddress: "keda-add-ons-http-external-scaler.keda:9090" interceptorRoute: "my-app" ``` Note the following conversions: 1. `scaleTargetRef` becomes `target` with only `service` and `port`/`portName`. 2. `hosts`, `pathPrefixes`, and `headers` move into a `rules[]` entry. 3. `pathPrefixes` entries become `paths` entries, each with a `value` field. 4. `coldStartTimeoutFailoverRef` splits: the service reference moves to `coldStart.fallback`, and `timeoutSeconds` moves to `timeouts.readiness` as a duration string (`"45s"`). 5. `replicas`, `scaledownPeriod`, and `initialCooldownPeriod` move to the `ScaledObject`. 6. The workload reference (`name`, `apiVersion`, `kind`) moves to the `ScaledObject`'s `scaleTargetRef`. ## Apply the migration without downtime The `HTTPScaledObject` controller sets an owner reference on the KEDA `ScaledObject` it creates. Deleting the `HTTPScaledObject` triggers Kubernetes garbage collection, which cascade-deletes the owned `ScaledObject`. To prevent this, add the `httpscaledobject.keda.sh/orphan-scaledobject` annotation to the `HTTPScaledObject` before deleting it. The controller removes the owner reference from the `ScaledObject`, so it survives deletion. Set these environment variables before running the commands: ```bash NAME=my-app NAMESPACE=default ``` 1. Annotate the `HTTPScaledObject` to orphan its `ScaledObject`: ```bash kubectl annotate httpscaledobject $NAME -n $NAMESPACE \ httpscaledobject.keda.sh/orphan-scaledobject=true ``` The controller removes the owner reference from the `ScaledObject`. Verify that the owner reference was removed: ```bash kubectl get scaledobject $NAME -n $NAMESPACE \ -o jsonpath='{.metadata.ownerReferences}' ``` The output is empty when the owner reference has been removed. 2. Create the `InterceptorRoute`: ```bash kubectl apply -f interceptor-route.yaml ``` When the `InterceptorRoute` shares the same namespace and name as the `HTTPScaledObject`, the routing table automatically gives the `InterceptorRoute` precedence and skips the `HTTPScaledObject`. 3. Update the `ScaledObject` trigger metadata. The auto-created `ScaledObject` references the `HTTPScaledObject` by name in its trigger metadata. Replace `httpScaledObject` with `interceptorRoute` so the external scaler resolves metrics from the `InterceptorRoute`: ```bash kubectl patch scaledobject $NAME -n $NAMESPACE --type=json \ -p '[{"op": "remove", "path": "/spec/triggers/0/metadata/httpScaledObject"}, {"op": "add", "path": "/spec/triggers/0/metadata/interceptorRoute", "value": "'$NAME'"}]' ``` Also compare the remaining fields with the ScaledObject YAML from the conversion example and adjust `minReplicaCount`, `maxReplicaCount`, or `cooldownPeriod` as needed. 4. Verify the `ScaledObject` is still present and active: ```bash kubectl get scaledobject $NAME -n $NAMESPACE ``` 5. Delete the old `HTTPScaledObject`: ```bash kubectl delete httpscaledobject $NAME -n $NAMESPACE ``` The `ScaledObject` remains in the cluster because the owner reference was removed in step 1. > **GitOps:** In one commit, add the orphan annotation to the `HTTPScaledObject` manifest, add the `InterceptorRoute` manifest, and update the `ScaledObject` trigger metadata (`httpScaledObject` → `interceptorRoute`). > In the next commit, remove the `HTTPScaledObject` manifest. ## Field mapping ### HTTPScaledObject → InterceptorRoute | HTTPScaledObject field | InterceptorRoute field | | ------------------------------------------------- | ------------------------------------------------------- | | `spec.hosts` | `spec.rules[].hosts` | | `spec.pathPrefixes` | `spec.rules[].paths[].value` | | `spec.headers` | `spec.rules[].headers` | | `spec.scaleTargetRef.service` | `spec.target.service` | | `spec.scaleTargetRef.port` | `spec.target.port` | | `spec.scaleTargetRef.portName` | `spec.target.portName` | | `spec.coldStartTimeoutFailoverRef.service` | `spec.coldStart.fallback.service` | | `spec.coldStartTimeoutFailoverRef.port` | `spec.coldStart.fallback.port` | | `spec.coldStartTimeoutFailoverRef.portName` | `spec.coldStart.fallback.portName` | | `spec.coldStartTimeoutFailoverRef.timeoutSeconds` | `spec.timeouts.readiness` (as `Duration`, e.g. `"30s"`) | | `spec.scalingMetric.concurrency.targetValue` | `spec.scalingMetric.concurrency.targetValue` | | `spec.scalingMetric.requestRate.targetValue` | `spec.scalingMetric.requestRate.targetValue` | | `spec.scalingMetric.requestRate.window` | `spec.scalingMetric.requestRate.window` | | `spec.scalingMetric.requestRate.granularity` | `spec.scalingMetric.requestRate.granularity` | | `spec.targetPendingRequests` | `spec.scalingMetric` | | `spec.timeouts.conditionWait` | `spec.timeouts.readiness` | | `spec.timeouts.responseHeader` | `spec.timeouts.responseHeader` | | _(new)_ | `spec.timeouts.request` | ### HTTPScaledObject → ScaledObject | HTTPScaledObject field | ScaledObject field | | -------------------------------- | -------------------------------- | | `spec.scaleTargetRef.name` | `spec.scaleTargetRef.name` | | `spec.scaleTargetRef.apiVersion` | `spec.scaleTargetRef.apiVersion` | | `spec.scaleTargetRef.kind` | `spec.scaleTargetRef.kind` | | `spec.replicas.min` | `spec.minReplicaCount` | | `spec.replicas.max` | `spec.maxReplicaCount` | | `spec.scaledownPeriod` | `spec.cooldownPeriod` | | `spec.initialCooldownPeriod` | `spec.initialCooldownPeriod` | ## What's Next - [Configure Routing Rules](../../user-guide/configure-routing/) — multiple rules, host, path, and header matching on an InterceptorRoute. - [Configure Scaling Metrics](../../user-guide/configure-scaling/) — concurrency, request rate, and combined metric configuration. - [InterceptorRoute Reference](../../reference/interceptorroute/) — full API specification. - [KEDA ScaledObject documentation](https://keda.sh/docs/latest/concepts/scaling-deployments/) — scaling configuration options. ================================================ FILE: content/http-add-on/0.14/operations/troubleshooting.md ================================================ +++ title = "Troubleshooting" description = "Request routing, queue state, and component performance troubleshooting" +++ ## Queue inspection The interceptor exposes a `/queue` endpoint on its admin service (port `9090` by default) that returns the current pending request counts per route as JSON. ```shell kubectl port-forward -n keda svc/keda-add-ons-http-interceptor-admin 9090 ``` ```shell curl -X GET localhost:9090/queue ``` The response is a JSON object keyed by `namespace/route-name`, with concurrency and request count for each route: ```json { "default/my-app": { "Concurrency": 3, "RequestCount": 42 }, "demo/sample-app": { "Concurrency": 0, "RequestCount": 0 } } ``` The endpoint shows raw counts from the interceptor. Request rate (RPS) is calculated by the scaler component based on these counts and the configured window — it is not part of this response. ## Profiling Enable pprof profiling on the interceptor or scaler by setting the `PROFILING_BIND_ADDRESS` environment variable: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set interceptor.extraEnvs.PROFILING_BIND_ADDRESS=0.0.0.0:6060 ``` For the operator, use the `--profiling-bind-address` flag instead: ```shell helm upgrade http-add-on kedacore/keda-add-ons-http \ --namespace keda \ --set operator.extraArgs.profiling-bind-address=:6060 ``` Once enabled, collect profiles with `go tool pprof`: ```shell kubectl port-forward -n keda deploy/keda-add-ons-http-interceptor 6060 go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap ``` ## Getting Help If you cannot resolve the issue, the following channels are available: - [Kubernetes Slack](https://kubernetes.slack.com/archives/CKZJ36A5D) — `#keda` channel ([join here](https://slack.k8s.io)) - [GitHub Issues](https://github.com/kedacore/http-add-on/issues) — Bug reports and feature requests - [GitHub Discussions](https://github.com/kedacore/http-add-on/discussions) — Questions and general conversation ## What's Next - [Configure the Interceptor](../configure-interceptor/) — Timeouts, connection tuning, and scaling. - [Environment Variables Reference](../../reference/environment-variables/) — all environment variables for each component. - [Metrics Reference](../../reference/metrics/) — Prometheus metric definitions for monitoring. ================================================ FILE: content/http-add-on/0.14/reference/_index.md ================================================ +++ title = "Reference" description = "API specifications, environment variables, and metrics" weight = 500 +++ - **[Environment Variables](environment-variables/)** — Environment variables for each component. - **[HTTPScaledObject](httpscaledobject/)** — HTTPScaledObject CRD API reference (v1alpha1, deprecated). - **[InterceptorRoute](interceptorroute/)** — InterceptorRoute CRD API reference (v1beta1). - **[Metrics](metrics/)** — Prometheus metrics exposed by the interceptor. ================================================ FILE: content/http-add-on/0.14/reference/environment-variables.md ================================================ +++ title = "Environment Variables" description = "Reference for all environment variables accepted by each component" +++ Environment variables configure runtime behavior for each HTTP Add-on component. These are set via the `extraEnvs` Helm value for each component or directly in the container spec. ## Interceptor ### Serving | Variable | Default | Description | | --------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------- | | `KEDA_HTTP_PROXY_PORT` | _(required)_ | Port for the public proxy server. | | `KEDA_HTTP_ADMIN_PORT` | _(required)_ | Port for the internal admin server (metrics RPC endpoint for the scaler). | | `KEDA_HTTP_WATCH_NAMESPACE` | `""` | Namespace to watch for HTTPScaledObjects and InterceptorRoutes. Empty watches all namespaces. | | `KEDA_HTTP_SCALER_CONFIG_MAP_INFORMER_RSYNC_PERIOD` | `60m` | Resync interval for the controller-runtime cache. | | `KEDA_HTTP_ENABLE_COLD_START_HEADER` | `true` | When enabled, the interceptor adds the `X-KEDA-HTTP-Cold-Start` response header. | | `KEDA_HTTP_LOG_REQUESTS` | `false` | Enable logging of incoming requests. | ### Timeouts | Variable | Default | Description | | ----------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `KEDA_HTTP_REQUEST_TIMEOUT` | `0s` | Total request lifecycle deadline. `0s` disables the deadline. | | `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | `300s` | Time to wait for response headers from the backend after the request is sent. `0s` disables the deadline. | | `KEDA_HTTP_READINESS_TIMEOUT` | `0s` | Time to wait for the backing workload to reach 1 or more replicas. `0s` disables the dedicated readiness deadline, giving the full request budget to cold starts. When a fallback service is configured and this is `0s`, a 30s default is applied. | | `KEDA_HTTP_CONNECT_TIMEOUT` | `500ms` | Per-attempt TCP dial timeout. Bounded by the request context deadline. | | `KEDA_HTTP_MAX_IDLE_CONNS` | `1000` | Maximum idle connections in the connection pool across all backend services. | | `KEDA_HTTP_MAX_IDLE_CONNS_PER_HOST` | `200` | Maximum idle connections per backend service. | | `KEDA_HTTP_FORCE_HTTP2` | `false` | Whether to force HTTP/2 for all proxied requests. | #### Deprecated timeout variables These deprecated variables are still accepted. When set, they take precedence over their replacements. | Deprecated Variable | Replacement | Description | | ------------------------------ | ----------------------------------- | ----------------------------------------------------------------- | | `KEDA_CONDITION_WAIT_TIMEOUT` | `KEDA_HTTP_READINESS_TIMEOUT` | Time to wait for the backing workload to have 1 or more replicas. | | `KEDA_RESPONSE_HEADER_TIMEOUT` | `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | Time to wait for response headers from the backend. | ### TLS | Variable | Default | Description | | --------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------- | | `KEDA_HTTP_PROXY_TLS_ENABLED` | `false` | Enable TLS on the proxy server. | | `KEDA_HTTP_PROXY_TLS_CERT_PATH` | `/certs/tls.crt` | Path to the TLS certificate file. | | `KEDA_HTTP_PROXY_TLS_KEY_PATH` | `/certs/tls.key` | Path to the TLS private key file. | | `KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHS` | `""` | Comma-separated list of paths to certificate/key pairs. | | `KEDA_HTTP_PROXY_TLS_SKIP_VERIFY` | `false` | Skip TLS verification for upstream connections. | | `KEDA_HTTP_PROXY_TLS_PORT` | `8443` | Port for the TLS proxy server. | | `KEDA_HTTP_PROXY_TLS_MIN_VERSION` | `""` | Minimum TLS version (`1.2` or `1.3`). Empty uses the Go default (TLS 1.2). | | `KEDA_HTTP_PROXY_TLS_MAX_VERSION` | `""` | Maximum TLS version (`1.2` or `1.3`). Empty uses the highest version supported by `crypto/tls`. | | `KEDA_HTTP_PROXY_TLS_CIPHER_SUITES` | `""` | Comma-separated list of TLS cipher suite names. Empty uses Go defaults. | | `KEDA_HTTP_PROXY_TLS_CURVE_PREFERENCES` | `""` | Comma-separated list of elliptic curve names. Empty uses Go defaults. | ### Metrics | Variable | Default | Description | | ------------------------------------ | ------- | ---------------------------------------------------- | | `OTEL_PROM_EXPORTER_ENABLED` | `true` | Enable the Prometheus metrics exporter. | | `OTEL_PROM_EXPORTER_PORT` | `2223` | Port for the Prometheus-compatible metrics endpoint. | | `OTEL_EXPORTER_OTLP_METRICS_ENABLED` | `false` | Enable the OTLP metrics exporter. | ### Tracing | Variable | Default | Description | | ------------------------------------ | --------- | ---------------------------------------------------------------------------- | | `OTEL_EXPORTER_OTLP_TRACES_ENABLED` | `false` | Enable OpenTelemetry trace export. | | `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` | `console` | Trace exporter protocol. Must be one of: `console`, `http/protobuf`, `grpc`. | ### Profiling | Variable | Default | Description | | ------------------------ | ------- | ----------------------------------------------------------------------- | | `PROFILING_BIND_ADDRESS` | `""` | Address (`host:port`) for the pprof endpoint. Empty disables profiling. | ## Scaler | Variable | Default | Description | | --------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------- | | `KEDA_HTTP_SCALER_PORT` | `8080` | Port for the KEDA-compatible gRPC external scaler interface. | | `KEDA_HTTP_SCALER_TARGET_ADMIN_NAMESPACE` | _(required)_ | Namespace where the scaler and interceptors are running. | | `KEDA_HTTP_SCALER_TARGET_ADMIN_SERVICE` | _(required)_ | Name of the interceptor admin Service to issue metrics RPC requests to. | | `KEDA_HTTP_SCALER_TARGET_ADMIN_DEPLOYMENT` | _(required)_ | Name of the interceptor Deployment to issue metrics RPC requests to. | | `KEDA_HTTP_SCALER_TARGET_ADMIN_PORT` | _(required)_ | Port on the interceptor admin Service for metrics RPC requests. | | `KEDA_HTTP_SCALER_CONFIG_MAP_INFORMER_RSYNC_PERIOD` | `60m` | Resync interval for the controller-runtime cache. | | `KEDA_HTTP_QUEUE_TICK_DURATION` | `500ms` | Duration between queue polling ticks. | | `KEDA_HTTP_SCALER_STREAM_INTERVAL_MS` | `200` | Interval in milliseconds between stream ticks for `IsActive` communication to KEDA. | | `PROFILING_BIND_ADDRESS` | `""` | Address (`host:port`) for the pprof endpoint. Empty disables profiling. | ## Operator | Variable | Default | Description | | --------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------- | | `KEDA_HTTP_OPERATOR_EXTERNAL_SCALER_SERVICE` | _(required)_ | Name of the Kubernetes Service for the external scaler. | | `KEDA_HTTP_OPERATOR_EXTERNAL_SCALER_PORT` | `8091` | Port for the external scaler Service. | | `KEDA_HTTP_OPERATOR_NAMESPACE` | `""` | Namespace in which the operator is running. | | `KEDA_HTTP_OPERATOR_WATCH_NAMESPACE` | `""` | Namespace to watch for resources. Empty watches all namespaces. | | `KEDA_HTTP_OPERATOR_LEADER_ELECTION_LEASE_DURATION` | _(unset)_ | Leader election lease duration. When unset, the controller-runtime default is used. | | `KEDA_HTTP_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE` | _(unset)_ | Leader election renew deadline. When unset, the controller-runtime default is used. | | `KEDA_HTTP_OPERATOR_LEADER_ELECTION_RETRY_PERIOD` | _(unset)_ | Leader election retry period. When unset, the controller-runtime default is used. | ================================================ FILE: content/http-add-on/0.14/reference/httpscaledobject.md ================================================ +++ title = "HTTPScaledObject (Deprecated)" description = "Field-by-field API reference for the HTTPScaledObject custom resource" +++ > **Deprecated:** HTTPScaledObject (v1alpha1) is deprecated. > [InterceptorRoute](../interceptorroute/) (v1beta1) is the current API. > See [Migrate from HTTPScaledObject to InterceptorRoute](../../operations/migrate-httpscaledobject-to-interceptorroute/) to upgrade. | | | | --------------- | ----------------------- | | **API version** | `http.keda.sh/v1alpha1` | | **Kind** | `HTTPScaledObject` | | **Short name** | `httpso` | | **Scope** | Namespaced | ## Example ```yaml apiVersion: http.keda.sh/v1alpha1 kind: HTTPScaledObject metadata: name: my-app namespace: default spec: hosts: - app.example.com pathPrefixes: - /api scaleTargetRef: name: my-app service: my-app-svc port: 8080 replicas: min: 0 max: 10 scalingMetric: concurrency: targetValue: 100 ``` ## Annotations | Annotation | Value | Description | | ----------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `httpscaledobject.keda.sh/skip-scaledobject-creation` | `"true"` | Skip automatic ScaledObject creation. Set this when you want to integrate the HTTP scaler with other KEDA scalers in a single ScaledObject that you manage yourself. | | `httpscaledobject.keda.sh/orphan-scaledobject` | `"true"` | When the HTTPScaledObject is deleted, leave the generated ScaledObject in place instead of deleting it. | When `skip-scaledobject-creation` is set to `"true"`, the operator does not create or manage a ScaledObject. You can then create your own ScaledObject and add the HTTP external scaler as one of the triggers: ```yaml triggers: - type: external-push metadata: httpScaledObject: scalerAddress: keda-add-ons-http-external-scaler.keda:9090 ``` > **Note:** The InterceptorRoute API does not use this annotation. > InterceptorRoute separates routing from scaling by design — you always create your own ScaledObject. ## `spec` | Field | Type | Required | Default | Description | | ----------------------------- | ---------------------------------------------------------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `hosts` | `[]string` | No | | Hostnames to route. Requests whose `Host` header matches any entry (combined with `pathPrefixes`) are routed to the target. | | `pathPrefixes` | `[]string` | No | | URL path prefixes to match. Combined with `hosts` for routing. | | `headers` | [`[]Header`](#header) | No | | Custom headers for routing. After `hosts` and `pathPrefixes` match, requests must also match all listed headers. The interceptor uses the most specific header match. | | `scaleTargetRef` | [`ScaleTargetRef`](#scaletargetref) | Yes | | The target workload and service to scale and route to. | | `coldStartTimeoutFailoverRef` | [`*ColdStartTimeoutFailoverRef`](#coldstarttimeoutfailoverref) | No | | Failover service to route to when the target is not available during cold start. | | `replicas` | [`*ReplicaStruct`](#replicastruct) | No | | Minimum and maximum replica counts. | | `targetPendingRequests` | `*int32` | No | `100` | **Deprecated.** Use `scalingMetric` instead. Target metric value for the HPA. | | `scaledownPeriod` | `*int32` | No | `300` | Cooldown period in seconds before resources scale down. | | `initialCooldownPeriod` | `*int32` | No | `0` | Initial period in seconds before scaling begins. | | `scalingMetric` | [`*ScalingMetricSpec`](#scalingmetricspec) | No | | Configuration for the scaling metric. When empty, concurrency-based scaling is used. | | `timeouts` | [`*HTTPScaledObjectTimeoutsSpec`](#httpscaledobjecttimeoutsspec) | No | | Per-object timeout overrides for the global interceptor timeouts. | ### `ScaleTargetRef` | Field | Type | Required | Default | Description | | ------------ | -------- | -------- | ------- | --------------------------------------------------------------- | | `name` | `string` | No | | Name of the Deployment or StatefulSet to scale. | | `apiVersion` | `string` | No | | API version of the target workload. | | `kind` | `string` | No | | Kind of the target workload. | | `service` | `string` | Yes | | Name of the Kubernetes Service to route to. | | `port` | `int32` | No | | Port number on the Service. Mutually exclusive with `portName`. | | `portName` | `string` | No | | Named port on the Service. Mutually exclusive with `port`. | **Validation:** Exactly one of `port` or `portName` must be set. ### `Header` | Field | Type | Required | Default | Description | | ------- | --------- | -------- | ------- | ----------------------------------------------------------------------------------------------- | | `name` | `string` | Yes | | Name of the HTTP header. Minimum length: 1. | | `value` | `*string` | No | | Value to match (exact match). If omitted, the header must be present but any value is accepted. | ### `ReplicaStruct` | Field | Type | Required | Default | Description | | ----- | -------- | -------- | ------- | ---------------------- | | `min` | `*int32` | No | `0` | Minimum replica count. | | `max` | `*int32` | No | `100` | Maximum replica count. | ### `ScalingMetricSpec` `concurrency` and `requestRate` are mutually exclusive. Setting both produces undefined behavior. This differs from [InterceptorRoute](../interceptorroute/), which allows both to be set simultaneously. | Field | Type | Required | Default | Description | | ------------- | -------------------------------------------------- | -------- | ------- | ------------------------------------------------------- | | `concurrency` | [`*ConcurrencyMetricSpec`](#concurrencymetricspec) | No | | Scale based on concurrent requests. | | `requestRate` | [`*RateMetricSpec`](#ratemetricspec) | No | | Scale based on average request rate over a time window. | ### `ConcurrencyMetricSpec` | Field | Type | Required | Default | Description | | ------------- | ----- | -------- | ------- | -------------------------------------------- | | `targetValue` | `int` | No | `100` | Target concurrent request count per replica. | ### `RateMetricSpec` | Field | Type | Required | Default | Description | | ------------- | ---------- | -------- | ------- | -------------------------------------- | | `targetValue` | `int` | No | `100` | Target request rate per replica. | | `window` | `Duration` | No | `1m` | Time window for rate calculation. | | `granularity` | `Duration` | No | `1s` | Time granularity for rate calculation. | ### `ColdStartTimeoutFailoverRef` | Field | Type | Required | Default | Description | | ---------------- | -------- | -------- | ------- | ------------------------------------------------------- | | `service` | `string` | Yes | | Name of the failover Service to route to. | | `port` | `int32` | No | | Port number on the failover Service. | | `portName` | `string` | No | | Named port on the failover Service. | | `timeoutSeconds` | `int32` | No | `30` | Seconds to wait before routing to the failover service. | **Validation:** Exactly one of `port` or `portName` must be set. ### `HTTPScaledObjectTimeoutsSpec` | Field | Type | Required | Default | Description | | ---------------- | ---------- | -------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | `conditionWait` | `Duration` | No | Global `KEDA_CONDITION_WAIT_TIMEOUT` | Time to wait for the backing workload to reach 1 or more replicas before connecting and sending the HTTP request. | | `responseHeader` | `Duration` | No | Global `KEDA_RESPONSE_HEADER_TIMEOUT` | Time to wait for response headers after the HTTP request is sent to the backing application. | ## `status` | Field | Type | Description | | ---------------- | -------------------- | ---------------------------------------------------- | | `targetWorkload` | `string` | Resolved target workload reference. | | `targetService` | `string` | Resolved target service reference. | | `conditions` | `[]metav1.Condition` | Conditions of the HTTPScaledObject. Keyed by `type`. | ### Condition types | Type | Description | | ------- | --------------------------------------------------------------------- | | `Ready` | Whether the HTTPScaledObject is fully reconciled and routing traffic. | ================================================ FILE: content/http-add-on/0.14/reference/interceptorroute.md ================================================ +++ title = "InterceptorRoute" description = "Field-by-field API reference for the InterceptorRoute custom resource" +++ | | | | --------------- | ---------------------- | | **API version** | `http.keda.sh/v1beta1` | | **Kind** | `InterceptorRoute` | | **Scope** | Namespaced | ## Example ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app namespace: default spec: target: service: my-app-svc port: 8080 rules: - hosts: - app.example.com paths: - value: /api scalingMetric: concurrency: targetValue: 100 ``` ## `spec` | Field | Type | Required | Default | Description | | --------------- | ------------------------------------------------------- | -------- | ------- | ------------------------------------------------------------------ | | `target` | [`TargetRef`](#targetref) | Yes | | Backend service to route traffic to. | | `rules` | [`[]RoutingRule`](#routingrule) | No | | Routing rules that define how requests are matched to this target. | | `scalingMetric` | [`ScalingMetricSpec`](#scalingmetricspec) | Yes | | Metric configuration for autoscaling. | | `coldStart` | [`ColdStartSpec`](#coldstartspec) | No | | Cold start behavior when scaling from zero. | | `timeouts` | [`InterceptorRouteTimeouts`](#interceptorroutetimeouts) | No | | Timeout configuration for request handling. | For usage guidance, see [Configure Routing Rules](../../user-guide/configure-routing/) and [Configure Scaling Metrics](../../user-guide/configure-scaling/). ### `TargetRef` Identifies a Service to route traffic to. Exactly one of `port` or `portName` must be set. | Field | Type | Required | Default | Description | | ---------- | -------- | -------- | ------- | ----------------------------------------------------------------------------- | | `service` | `string` | Yes | | Name of the Kubernetes Service. Minimum length: 1. | | `port` | `int32` | No | | Port number on the Service (1--65535). Mutually exclusive with `portName`. | | `portName` | `string` | No | | Named port on the Service. Minimum length: 1. Mutually exclusive with `port`. | **Validation:** Exactly one of `port` or `portName` must be set. Setting both or neither produces a validation error. ### `RoutingRule` Defines a set of matching criteria for routing requests. All specified fields within a single rule use AND semantics (host AND path AND headers must match). Multiple rules use OR semantics (any rule can match). | Field | Type | Required | Default | Description | | --------- | ------------------------------- | -------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `hosts` | `[]string` | No | | Hostnames to match. Wildcard patterns (e.g., `*.example.com`) are supported. A single `*` acts as a catch-all. Exact matches take priority over wildcards; more specific wildcards (e.g., `*.bar.example.com`) take priority over less specific ones. | | `paths` | [`[]PathMatch`](#pathmatch) | No | | Path prefixes to match. When multiple paths match, the longest prefix wins. | | `headers` | [`[]HeaderMatch`](#headermatch) | No | | Headers that must all match the request (AND semantics). | ### `PathMatch` | Field | Type | Required | Default | Description | | ------- | -------- | -------- | ------- | ---------------------------------------------------------------------------------- | | `value` | `string` | Yes | | Path prefix to match against. The longest matching prefix wins. Minimum length: 1. | ### `HeaderMatch` | Field | Type | Required | Default | Description | | ------- | --------- | -------- | ------- | ---------------------------------------------------------------------------------------------- | | `name` | `string` | Yes | | Name of the HTTP header. Minimum length: 1. | | `value` | `*string` | No | | Value to match against (exact match). If omitted, matches any value for the given header name. | ### `ScalingMetricSpec` Defines what metric drives autoscaling. At least one of `concurrency` or `requestRate` must be set. When both are set, both metrics are reported and KEDA scales based on whichever demands more replicas. | Field | Type | Required | Default | Description | | ------------- | -------------------------------------------------- | -------- | ------- | ---------------------------------------- | | `concurrency` | [`*ConcurrencyTargetSpec`](#concurrencytargetspec) | No | | Scale based on concurrent request count. | | `requestRate` | [`*RequestRateTargetSpec`](#requestratetargetspec) | No | | Scale based on request rate. | **Validation:** At least one of `concurrency` or `requestRate` must be set. ### `ConcurrencyTargetSpec` | Field | Type | Required | Default | Description | | ------------- | ------- | -------- | ------- | -------------------------------------------------------- | | `targetValue` | `int32` | Yes | | Target concurrent request count per replica. Minimum: 1. | ### `RequestRateTargetSpec` | Field | Type | Required | Default | Description | | ------------- | ---------- | -------- | ------- | -------------------------------------------------------------- | | `targetValue` | `int32` | Yes | | Target request rate per replica. Minimum: 1. | | `window` | `Duration` | No | `1m` | Sliding time window over which the request rate is calculated. | | `granularity` | `Duration` | No | `1s` | Bucket size for rate calculation within the window. | ### `ColdStartSpec` Configures behavior while the target is not ready (scaling from zero). | Field | Type | Required | Default | Description | | ---------- | -------------------------- | -------- | ------- | ----------------------------------------------------------------------------------------------- | | `fallback` | [`*TargetRef`](#targetref) | Yes | | Fallback service to route to when the target is scaling from zero and the wait timeout expires. | **Validation:** The `fallback` field must be set. ### `InterceptorRouteTimeouts` Configures per-route request handling timeouts. When a field is unset, the global interceptor timeout configuration (`KEDA_HTTP_*_TIMEOUT` environment variables) is used. | Field | Type | Required | Default | Description | | ---------------- | ----------- | -------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `readiness` | `*Duration` | No | Global `KEDA_HTTP_READINESS_TIMEOUT` | Time to wait for the backend to become ready (e.g., scale from zero). Set to `0s` to disable the dedicated readiness deadline so the full request budget is available for cold starts. When a fallback service is configured and this is `0s`, a 30s default is applied. | | `request` | `*Duration` | No | Global `KEDA_HTTP_REQUEST_TIMEOUT` | Total time allowed for the entire request lifecycle. Set to `0s` to disable the request deadline. | | `responseHeader` | `*Duration` | No | Global `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | Maximum time to wait for response headers from the backend after the request has been sent. Does not include cold-start wait time. Set to `0s` to disable the response header deadline. | ## `status` | Field | Type | Description | | ------------ | -------------------- | ---------------------------------------------------- | | `conditions` | `[]metav1.Condition` | Conditions of the InterceptorRoute. Keyed by `type`. | ### Condition types | Type | Description | | ------- | --------------------------------------------------------------------- | | `Ready` | Whether the InterceptorRoute is fully reconciled and routing traffic. | ================================================ FILE: content/http-add-on/0.14/reference/metrics.md ================================================ +++ title = "Metrics" description = "Reference for all Prometheus metrics exposed by the HTTP Add-on" +++ The interceptor exposes metrics via OpenTelemetry, with a Prometheus-compatible endpoint enabled by default. ## Endpoint configuration | Setting | Default | Description | | ------- | ---------- | ---------------------------------------------- | | Port | `2223` | Configurable via `OTEL_PROM_EXPORTER_PORT`. | | Path | `/metrics` | Standard Prometheus scrape path. | | Enabled | `true` | Configurable via `OTEL_PROM_EXPORTER_ENABLED`. | The interceptor also supports OTLP metric export. See [Environment Variables](../environment-variables/#metrics) for configuration. ## Metrics ### Request count | | | | ------------------------ | -------------------------------------------------- | | **Prometheus name** | `interceptor_request_count_total` | | **OTel instrument name** | `interceptor.request.count` | | **Type** | Counter | | **Description** | Total requests processed by the interceptor proxy. | **Labels:** | Label | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------- | | `code` | HTTP response status code (integer). | | `method` | HTTP request method. Non-standard methods are normalized to `_OTHER` (see [Method normalization](#method-normalization)). | | `route_name` | Name of the matched InterceptorRoute or HTTPScaledObject. | | `route_namespace` | Namespace of the matched route resource. | ### Request concurrency | | | | ------------------------ | ------------------------------------------------------ | | **Prometheus name** | `interceptor_request_concurrency` | | **OTel instrument name** | `interceptor.request.concurrency` | | **Type** | UpDownCounter (gauge) | | **Description** | Requests currently in-flight at the interceptor proxy. | **Labels:** | Label | Description | | ----------------- | --------------------------------------------------------- | | `route_name` | Name of the matched InterceptorRoute or HTTPScaledObject. | | `route_namespace` | Namespace of the matched route resource. | ### Request duration | | | | ------------------------ | ----------------------------------------------- | | **Prometheus name** | `interceptor_request_duration_seconds` | | **OTel instrument name** | `interceptor.request.duration` | | **Type** | Histogram | | **Unit** | Seconds | | **Description** | Time from request received to response written. | **Bucket boundaries:** `0.005`, `0.01`, `0.025`, `0.05`, `0.075`, `0.1`, `0.25`, `0.5`, `0.75`, `1`, `2.5`, `5`, `7.5`, `10` (following the [OTel HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/http-metrics/)). **Labels:** | Label | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------- | | `code` | HTTP response status code (integer). | | `method` | HTTP request method. Non-standard methods are normalized to `_OTHER` (see [Method normalization](#method-normalization)). | | `route_name` | Name of the matched InterceptorRoute or HTTPScaledObject. | | `route_namespace` | Namespace of the matched route resource. | ## Method normalization The `method` label accepts the following standard HTTP methods without modification: `CONNECT`, `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, `PUT`, `TRACE` All other method values are replaced with `_OTHER` to prevent unbounded label cardinality. ================================================ FILE: content/http-add-on/0.14/user-guide/_index.md ================================================ +++ title = "User Guide" description = "Autoscaling, routing, and timeout configuration for HTTP applications" weight = 300 +++ Guides for application developers using the HTTP Add-on to autoscale their services. - **[Autoscale an App](autoscale-an-app/)** — Create a ScaledObject and InterceptorRoute for your service. - **[Configure Cold-Start Behavior](configure-cold-start/)** — Fallback services and cold-start response headers. - **[Configure Ingress](configure-ingress/)** — Point your Gateway API or Ingress at the interceptor proxy. - **[Configure Routing Rules](configure-routing/)** — Host, path, and header matching. - **[Configure Scaling Metrics](configure-scaling/)** — Choose between concurrency and request rate metrics. - **[Configure Timeouts](configure-timeouts/)** — Per-route timeout overrides. ================================================ FILE: content/http-add-on/0.14/user-guide/autoscale-an-app.md ================================================ +++ title = "Autoscale an App" description = "ScaledObject and InterceptorRoute configuration for autoscaling an HTTP service" +++ This guide walks you through the two resources needed to autoscale an existing HTTP service with the KEDA HTTP Add-on: an `InterceptorRoute` and a KEDA `ScaledObject`. ## Prerequisites - The HTTP Add-on is [installed](../operations/installation/) in your cluster. - You have an existing Deployment (or other workload) and a Service for your HTTP application. ## Step 1: Create an InterceptorRoute The `InterceptorRoute` tells the interceptor how to route requests to your service and what scaling metrics to report. ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: namespace: spec: target: service: port: 80 rules: - hosts: - scalingMetric: concurrency: targetValue: 100 ``` Key fields: - **`target.service`** / **`target.port`** — The Kubernetes Service and port to route traffic to. - **`rules[].hosts`** — Hostnames to match against the HTTP `Host` header. This must match what callers send (see [Step 4](#step-4-route-traffic-through-the-interceptor)): - External traffic: your public hostname (e.g., `app.example.com`). - In-cluster traffic: the service name callers use (e.g., `-proxy`). - Wildcards like `*.example.com` are supported. - **`scalingMetric.concurrency.targetValue`** — Target concurrent requests per replica. KEDA scales replicas so each handles approximately this many concurrent requests. ## Step 2: Create a ScaledObject The `ScaledObject` tells KEDA how to scale your workload. It references the HTTP Add-on's scaler using the `external-push` trigger type. > **Create the ScaledObject after the InterceptorRoute.** When KEDA reconciles a ScaledObject with an `external-push` trigger, it calls the scaler's `GetMetricSpec` endpoint. If the InterceptorRoute does not exist yet, the scaler returns an empty metric spec and KEDA falls back to a default CPU metric in the HPA, which prevents scale-up from working. ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: namespace: spec: scaleTargetRef: name: minReplicaCount: 0 maxReplicaCount: 10 cooldownPeriod: 300 triggers: - type: external-push metadata: scalerAddress: keda-add-ons-http-external-scaler.keda:9090 interceptorRoute: ``` Key fields: - **`scaleTargetRef.name`** — The name of the Deployment (or StatefulSet, etc.) to scale. - **`minReplicaCount`** — Set to `0` for scale-to-zero, or higher to keep a minimum number of replicas running. - **`maxReplicaCount`** — Upper bound for the number of replicas. - **`cooldownPeriod`** — Seconds to wait before scaling down after traffic stops (default: `300`). - **`scalerAddress`** — The HTTP Add-on scaler gRPC service address. If KEDA is installed in a namespace other than `keda`, adjust accordingly. - **`interceptorRoute`** — Must match the `metadata.name` of the InterceptorRoute created in the previous step. ## Step 3: Verify 1. Check that the ScaledObject is ready: ```shell kubectl get scaledobject -n ``` The `READY` column should show `True`. 2. Check that the InterceptorRoute is ready: ```shell kubectl get interceptorroute -n ``` The `READY` column should show `True`. ## Step 4: Route Traffic Through the Interceptor For autoscaling to work, traffic must flow through the interceptor instead of directly to your application. This applies to both in-cluster and external traffic. ### In-cluster traffic If other services in your cluster call your application directly, redirect them to the interceptor proxy service (`keda-add-ons-http-interceptor-proxy` in the `keda` namespace). Create an `ExternalName` service in your application's namespace so callers can reach the interceptor: ```yaml apiVersion: v1 kind: Service metadata: name: -proxy namespace: spec: type: ExternalName externalName: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local ports: - port: 8080 ``` Update callers to use `-proxy` instead of ``. The `hosts` in your InterceptorRoute must include the hostname that callers use in the `Host` header — typically the service name (e.g., `-proxy` or `-proxy..svc.cluster.local`). ### External traffic For traffic entering the cluster from outside, configure your ingress or gateway to point at the interceptor proxy service instead of your application. See [Configure Ingress](../configure-ingress/) for Gateway API, Ingress, and Istio examples. ## What's Next - **[Configure Routing Rules](../configure-routing/)** — Add path prefixes, wildcards, or header matching. - **[Configure Scaling Metrics](../configure-scaling/)** — Switch to request rate or use both concurrency and rate metrics. ================================================ FILE: content/http-add-on/0.14/user-guide/configure-cold-start.md ================================================ +++ title = "Configure Cold-Start Behavior" description = "Fallback services and response headers for cold-start scenarios" +++ When a request arrives for a backend that has been scaled to zero, the interceptor holds the request until the backend becomes ready. You can configure a fallback service and a readiness timeout to control what happens if the backend takes too long to start. ## Cold-start fallback When the readiness timeout expires during a cold start, the interceptor returns an error by default. To serve requests from a fallback service instead, configure the `coldStart.fallback` field: ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: concurrency: targetValue: 100 coldStart: fallback: service: port: timeouts: readiness: 5s ``` When a fallback is configured but the readiness timeout is `0s` (disabled), a 30-second default readiness timeout is applied automatically. This prevents the fallback from never being triggered. ## Cold-start response header The interceptor adds an `X-KEDA-HTTP-Cold-Start` response header to indicate whether a cold start occurred: - `X-KEDA-HTTP-Cold-Start: true` — the request triggered a scale-from-zero. - `X-KEDA-HTTP-Cold-Start: false` — the backend was already running. This header is enabled by default. To disable it, see [Configure the Interceptor](../operations/configure-interceptor/#cold-start-response-header). ## What's Next - [How Scaling Works](../concepts/scaling/) — cold-start mechanics and scale-from-zero behavior. - [Configure Timeouts](../configure-timeouts/) — per-route timeout overrides. - [InterceptorRoute Reference](../reference/interceptorroute/) — field details for `coldStart`. ================================================ FILE: content/http-add-on/0.14/user-guide/configure-ingress.md ================================================ +++ title = "Configure Ingress" description = "Gateway API and Ingress configuration for interceptor proxy traffic" +++ For the HTTP Add-on to intercept and scale your HTTP traffic, external requests must be routed to the **interceptor proxy service** (`keda-add-ons-http-interceptor-proxy`) instead of directly to your application. The interceptor then forwards requests to your application based on the InterceptorRoute configuration. The HTTP Add-on is ingress-agnostic — it works with any ingress controller or Gateway API implementation. ## Using Gateway API [Gateway API](https://gateway-api.sigs.k8s.io/) is the recommended approach for new Kubernetes clusters. ### Step 1: Create an HTTPRoute Create an HTTPRoute that sends traffic to the interceptor proxy service: ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: namespace: spec: parentRefs: - name: namespace: hostnames: - rules: - backendRefs: - name: keda-add-ons-http-interceptor-proxy namespace: keda port: 8080 ``` The `hostnames` in the HTTPRoute should match the `hosts` in your InterceptorRoute so the interceptor can route the request correctly. ### Step 2: Create a ReferenceGrant Cross-namespace backend references require a `ReferenceGrant` in the `keda` namespace. This grants the HTTPRoute's namespace permission to reference the interceptor service: ```yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: ReferenceGrant metadata: name: allow-httproute-to-interceptor namespace: keda spec: from: - group: gateway.networking.k8s.io kind: HTTPRoute namespace: to: - group: "" kind: Service name: keda-add-ons-http-interceptor-proxy ``` If your HTTPRoute is in the same namespace as the interceptor (e.g., `keda`), you do not need a ReferenceGrant. ## Using Kubernetes Ingress Create an Ingress resource that routes traffic to the interceptor proxy service: ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: namespace: keda spec: rules: - host: http: paths: - path: / pathType: Prefix backend: service: name: keda-add-ons-http-interceptor-proxy port: number: 8080 ``` The Ingress resource should be in the same namespace as the interceptor service (default: `keda`). If your Ingress must live in a different namespace, create an `ExternalName` Service to reference the interceptor across namespaces. ## Using Istio Add the interceptor proxy service as a destination in your Istio `VirtualService`: ```yaml apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: namespace: spec: hosts: - gateways: - http: - route: - destination: host: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local port: number: 8080 ``` The `host` field uses the fully qualified service name because the VirtualService and the interceptor are in different namespaces. > **Note:** Creating the ReferenceGrant shown in the Gateway API section is not required for Istio — Istio's VirtualService uses DNS-based service discovery, not Kubernetes cross-namespace backend references. ## Verifying Traffic Flow 1. Confirm the interceptor proxy service exists: ```shell kubectl get svc keda-add-ons-http-interceptor-proxy -n keda ``` 2. Find your ingress endpoint. For Gateway API, check the Gateway's address: ```shell kubectl get gateway -n -o jsonpath='{.status.addresses[0].value}' ``` For Ingress, check the Ingress address: ```shell kubectl get ingress -n keda -o jsonpath='{.status.loadBalancer.ingress[0].ip}' ``` 3. Send a test request: ```shell curl http:/// ``` 4. Verify the request reached your application by checking your application logs or response. ## What's Next - [Architecture](../concepts/architecture/) — Understand how the interceptor fits into the request flow. - [Autoscale an App](../autoscale-an-app/) — Create the ScaledObject and InterceptorRoute resources. ================================================ FILE: content/http-add-on/0.14/user-guide/configure-routing.md ================================================ +++ title = "Configure Routing Rules" description = "Host, path, and header matching rules on an InterceptorRoute" +++ An `InterceptorRoute` uses **rules** to match incoming requests to a target service. Each rule can match on hostnames, path prefixes, and headers. A request that matches any rule in the list is routed to the target. ## Single host Route all traffic for a single hostname: ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: concurrency: targetValue: 100 rules: - hosts: - api.example.com ``` ## Multiple hosts Route traffic for several hostnames to the same target: ```yaml spec: rules: - hosts: - api.example.com - api.staging.example.com ``` ## Wildcard hosts Use a wildcard prefix to match any subdomain. `*.example.com` matches `foo.example.com`, `bar.baz.example.com`, and so on. ```yaml spec: rules: - hosts: - "*.example.com" ``` A single `*` acts as a catch-all that matches every hostname. When multiple wildcard patterns match a request, more specific wildcards take priority. For example, `*.bar.example.com` wins over `*.example.com`. Exact matches always take priority over wildcards. ## Path prefixes Add path prefixes to narrow a rule to specific URL paths: ```yaml spec: rules: - hosts: - api.example.com paths: - value: /api/v1 - value: /api/v2 ``` When multiple path prefixes match, the longest prefix wins. A request to `/api/v1/users` matches `/api/v1` over `/api`. ## Header matching Headers use AND semantics — all specified headers must match for the rule to apply. ### Match by exact value ```yaml spec: rules: - hosts: - api.example.com headers: - name: X-Route value: canary ``` ### Match by presence Omit the `value` field to match any request that includes the header, regardless of its value: ```yaml spec: rules: - hosts: - api.example.com headers: - name: X-Route ``` ## Multiple rules An `InterceptorRoute` can have multiple rules. A request matching **any** rule is routed to the same target: ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: concurrency: targetValue: 100 rules: - hosts: - api.example.com paths: - value: /api - hosts: - admin.example.com ``` In this example, requests to `api.example.com/api/*` and `admin.example.com/*` both route to the same service. ## Routing priority When rules from different `InterceptorRoute` resources overlap, the interceptor evaluates them in priority order: 1. Exact host matches beat wildcards. 2. More specific wildcards beat less specific ones. 3. Longer path prefixes beat shorter ones. 4. Header-matching rules beat rules without headers. For a detailed explanation, see [How Routing Works](../concepts/routing/). ## What's Next - [InterceptorRoute Reference](../reference/interceptorroute/) — complete field definitions for rules, hosts, paths, and headers. ================================================ FILE: content/http-add-on/0.14/user-guide/configure-scaling.md ================================================ +++ title = "Configure Scaling Metrics" description = "Autoscaling metric configuration on an InterceptorRoute" +++ The `scalingMetric` field on an `InterceptorRoute` determines what metric drives autoscaling. You can scale based on concurrent request count, request rate, or both. At least one metric must be set. ## Concurrency metric Scale based on the number of in-flight requests per replica: ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: concurrency: targetValue: 100 ``` The add-on targets `targetValue` concurrent requests per replica. When the total concurrent requests across all replicas exceeds `replicas * targetValue`, KEDA scales up. | Field | Required | Description | | ------------- | -------- | -------------------------------------------- | | `targetValue` | Yes | Target concurrent request count per replica. | ## Request rate metric Scale based on requests per second, averaged over a sliding window: ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: requestRate: targetValue: 100 window: 1m granularity: 1s ``` | Field | Required | Description | | ------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------- | | `targetValue` | Yes | Target requests per second per replica. | | `window` | `1m` | Sliding time window over which the average request rate is calculated. | | `granularity` | `1s` | Bucket size within the window. Smaller granularity gives more responsive scaling at the cost of higher sensitivity to bursts. | ## Using both metrics An `InterceptorRoute` can set both `concurrency` and `requestRate`. KEDA scales to whichever metric demands more replicas. ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: concurrency: targetValue: 50 requestRate: targetValue: 200 ``` This is useful when you want to handle both sustained throughput (rate) and bursty traffic (concurrency). ## Scaling boundaries and cooldown Minimum and maximum replica counts and cooldown are set on the KEDA `ScaledObject`, not the `InterceptorRoute`: ```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: my-app spec: scaleTargetRef: name: minReplicaCount: 0 # 0 enables scale-to-zero maxReplicaCount: 10 cooldownPeriod: 300 # seconds before scaling to zero after traffic stops ``` Setting `minReplicaCount: 0` enables scale-to-zero. The `cooldownPeriod` controls how long KEDA waits after the last request before scaling the workload down to zero replicas. ## What's Next - [How Scaling Works](../concepts/scaling/) — the full scaling mechanics, including scale-to-zero and cold starts. - [InterceptorRoute Reference](../reference/interceptorroute/) — field details for `scalingMetric`, `concurrency`, and `requestRate`. ================================================ FILE: content/http-add-on/0.14/user-guide/configure-timeouts.md ================================================ +++ title = "Configure Timeouts" description = "Per-route timeout configuration" +++ You can override the cluster-wide timeout defaults on individual routes using the `InterceptorRoute` spec. For global timeout defaults, see [Configure the Interceptor](../operations/configure-interceptor/#timeouts). ## Timeout types | Timeout | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Request** | Total deadline for the entire request lifecycle, from arrival to response completion. | | **Response header** | Maximum time to wait for the backend to send response headers after the request is forwarded. Does not include cold-start wait time. | | **Readiness** | Maximum time to wait for the backend to become ready during a cold start (scale from zero). | ## Per-route overrides Override timeouts for a specific route via the `InterceptorRoute` spec: ```yaml apiVersion: http.keda.sh/v1beta1 kind: InterceptorRoute metadata: name: my-app spec: target: service: port: scalingMetric: concurrency: targetValue: 100 timeouts: request: 60s responseHeader: 30s readiness: 10s ``` ### Override semantics - When a timeout field is **omitted** (not set) in the `InterceptorRoute`, the global default applies. - When a timeout field is set to **`0s`**, that timeout is disabled for this route. - When a timeout field is set to a **positive value**, it overrides the global default for this route. ## Timeout errors When a timeout is exceeded, the interceptor returns one of these HTTP status codes: | Condition | HTTP status | | ------------------------------------------------ | --------------------- | | Request timeout exceeded | `504 Gateway Timeout` | | Response header timeout exceeded | `504 Gateway Timeout` | | Readiness timeout exceeded (no fallback) | `504 Gateway Timeout` | | Backend error (non-timeout failure, no fallback) | `502 Bad Gateway` | ## What's Next - [Configure Cold-Start Behavior](../configure-cold-start/) — fallback services and cold-start response headers. - [Configure the Interceptor](../operations/configure-interceptor/#timeouts) — global timeout defaults. - [InterceptorRoute Reference](../reference/interceptorroute/) — field details for `timeouts`. ================================================ FILE: content/http-add-on/_index.md ================================================ --- build: render: false --- ================================================ FILE: content/resources.md ================================================ +++ title = "Resources" description = "Materials for learning more about KEDA" +++ ## Learning Courses - ["Scale container applications in Azure Kubernetes Services using KEDA"](https://docs.microsoft.com/en-us/learn/modules/aks-app-scale-keda/) on Microsoft Learn - ["Kubernetes Autoscaling"](https://learn.kodekloud.com/courses/kubernetes-autoscaling) on KodeKloud - ["Mastering Kubernetes Event-driven Autoscaling with KEDA (LFS257)"](https://training.linuxfoundation.org/training/mastering-kubernetes-event-driven-autoscaling-with-keda-lfs257/) on Linux Foundation ## Videos ### Application Autoscaling Made Easy with Kubernetes Event-driven Autoscaling (KEDA) [KubeCon Europe 2021](https://kccnceu2021.sched.com/event/iE5l/application-autoscaling-made-easy-with-kubernetes-event-driven-autoscaling-tom-kerkhove-codit) presented by [Tom Kerkhove](https://twitter.com/TomKerkhove). {{< youtube "H5eZEq_wqSE" >}} ### KEDA: Event-driven and Serverless Containers in Kubernetes [KubeCon North America 2019](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019) presentation by [Jeff Hollan](https://twitter.com/jeffhollan). {{< youtube "ZK2SS_GXF-g" >}} ================================================ FILE: content/support.md ================================================ +++ title = "Support" description = "Support for deploying and using KEDA" +++ ## Open-Source (OSS) support KEDA is an open-source project under the CNCF and is community-supported on a best-effort basis. Use GitHub to track bugs and feature requests. Want to contribute a feature or fix? We are more than happy to review requests and contributions, but recommend going through our [contribution guide](https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md). Learn more in our [support policy](https://github.com/kedacore/governance/blob/main/SUPPORT.md). Kubernetes compatibility and tested versions are described in the [documentation](https://keda.sh/docs/latest/operate/cluster/#kubernetes-compatibility). ## Commercial support Please refer to the [Enterprise page](enterprise) for details on commercially supported solutions based on KEDA. ================================================ FILE: content/troubleshooting/2.17/api-server-throttling.md ================================================ +++ title = "Troubleshooting API Server Throttling" description = "Learn how to troubleshoot and resolve KEDA API server throttling issues" weight = 500 +++ # Troubleshooting KEDA API Server Throttling If you are experiencing messages like "Waited for ... due to client-side throttling" in your KEDA operator logs, it might indicate that the KEDA operator is being throttled by the Kubernetes API server. This can happen in environments with a large number of `ScaledObject` resources. KEDA provides several command-line flags to control its interaction with the Kubernetes API server. Adjusting these flags can help alleviate client-side throttling. ## Key Configuration Parameters The following flags are relevant for tuning KEDA's API server interaction: * `--kube-api-qps` (Default: `20.0`): This flag sets the maximum queries per second (QPS) that the KEDA operator can make to the Kubernetes API server. * `--kube-api-burst` (Default: `30`): This flag sets the maximum burst of requests that the KEDA operator can make to the Kubernetes API server. The following env variable is relevant for tuning KEDA's API server interaction: * `KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES` (Default: `5`): This environment variable determines the maximum number of `ScaledObject` resources that the KEDA operator will reconcile concurrently. ## Recommendation for Adjusting Flags In environments with a large number of `ScaledObject` resources (e.g., 400 or more), the default values for these parameters might be too low. It is recommended to experiment with increasing the values of these parameters: * **`--kube-api-qps` and `--kube-api-burst`**: Increasing these values allows the KEDA operator to make more requests to the API server per unit of time. * Consider starting by doubling the default values (e.g., set `--kube-api-qps=40` and `--kube-api-burst=60`). * Monitor the impact on both KEDA's performance and the API server's load. * **`KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES`**: Increasing this value allows KEDA to process more `ScaledObject` resources in parallel. However, this will also increase the overall load on the API server. * Consider a moderate increase (e.g., to `10`). * Observe the performance and API server load. ## Important Considerations * **API Server Load:** Increasing these parameters will inevitably increase the load on the Kubernetes API server. It is crucial to monitor the API server's performance (CPU, memory, request latency) after making these changes to ensure it is not being overwhelmed. * **Gradual Adjustments:** Make adjustments to these parameters gradually. Monitor the system's behavior closely after each change. This iterative approach will help in finding the optimal values for your specific environment. * **Throttling vs. Server Overload:** While these adjustments can help with client-side throttling, if the API server itself is overloaded, these changes might exacerbate the problem. Ensure your Kubernetes API server has sufficient resources (CPU, memory) to handle the increased load. ## How to Apply Changes These flags are typically set when deploying the KEDA operator. You will need to update the KEDA operator's deployment manifest (e.g., its `Deployment` YAML) to include these flags in the `args` section of the operator container. **Example (partial Deployment YAML):** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator namespace: keda # Or your KEDA installation namespace spec: template: spec: containers: - name: keda-operator # Or keda-metrics-apiserver, depending on which component is throttled args: - "--kube-api-qps=40" - "--kube-api-burst=60" env: - name: KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES value: "10" # ... other existing arguments for the KEDA operator ``` ## Status Update Optimization As of recent versions of KEDA, the operator includes built-in optimizations to reduce unnecessary ScaledObject status updates. The operator now: - **Compares condition states**: Before updating status, KEDA compares the new conditions (Type, Status, Reason, and Message) with existing ones - **Skips redundant updates**: Status updates are only performed when conditions have actually changed - **Handles edge cases**: Properly distinguishes between empty condition sets and initialized conditions with 'Unknown' status This optimization is particularly beneficial in environments with many ScaledObjects, as it can significantly reduce the number of API calls made by the KEDA operator, helping to prevent API server throttling issues described above. For the most up-to-date information about this optimization, refer to the [KEDA CHANGELOG](https://github.com/kedacore/keda/blob/main/CHANGELOG.md). ## Expected Impact With proper configuration and built-in optimizations, users typically experience: - **Reduced throttling messages**: Fewer "client-side throttling" warnings in KEDA operator logs - **Lower API server load**: Decreased request volume from KEDA operations to the Kubernetes API server - **Improved performance**: Better responsiveness in environments with 100+ ScaledObjects - **More stable scaling**: Consistent autoscaling behavior without throttling-related delays ## Additional Troubleshooting By carefully tuning these parameters and leveraging KEDA's built-in optimizations, you should be able to reduce or eliminate the client-side throttling experienced by the KEDA operator. If throttling persists even after these adjustments, consider: - Further investigation into the API server's capacity and resource allocation - Reviewing your ScaledObject configurations for potential optimizations - Consulting the KEDA community for environment-specific guidance If issues continue, potential code-level optimizations within KEDA might be necessary, and feedback to the KEDA project maintainers would be valuable. ================================================ FILE: content/troubleshooting/2.18/api-server-throttling.md ================================================ +++ title = "Troubleshooting API Server Throttling" description = "Learn how to troubleshoot and resolve KEDA API server throttling issues" weight = 500 +++ # Troubleshooting KEDA API Server Throttling If you are experiencing messages like "Waited for ... due to client-side throttling" in your KEDA operator logs, it might indicate that the KEDA operator is being throttled by the Kubernetes API server. This can happen in environments with a large number of `ScaledObject` resources. KEDA provides several command-line flags to control its interaction with the Kubernetes API server. Adjusting these flags can help alleviate client-side throttling. ## Key Configuration Parameters The following flags are relevant for tuning KEDA's API server interaction: * `--kube-api-qps` (Default: `20.0`): This flag sets the maximum queries per second (QPS) that the KEDA operator can make to the Kubernetes API server. * `--kube-api-burst` (Default: `30`): This flag sets the maximum burst of requests that the KEDA operator can make to the Kubernetes API server. The following env variable is relevant for tuning KEDA's API server interaction: * `KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES` (Default: `5`): This environment variable determines the maximum number of `ScaledObject` resources that the KEDA operator will reconcile concurrently. ## Recommendation for Adjusting Flags In environments with a large number of `ScaledObject` resources (e.g., 400 or more), the default values for these parameters might be too low. It is recommended to experiment with increasing the values of these parameters: * **`--kube-api-qps` and `--kube-api-burst`**: Increasing these values allows the KEDA operator to make more requests to the API server per unit of time. * Consider starting by doubling the default values (e.g., set `--kube-api-qps=40` and `--kube-api-burst=60`). * Monitor the impact on both KEDA's performance and the API server's load. * **`KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES`**: Increasing this value allows KEDA to process more `ScaledObject` resources in parallel. However, this will also increase the overall load on the API server. * Consider a moderate increase (e.g., to `10`). * Observe the performance and API server load. ## Important Considerations * **API Server Load:** Increasing these parameters will inevitably increase the load on the Kubernetes API server. It is crucial to monitor the API server's performance (CPU, memory, request latency) after making these changes to ensure it is not being overwhelmed. * **Gradual Adjustments:** Make adjustments to these parameters gradually. Monitor the system's behavior closely after each change. This iterative approach will help in finding the optimal values for your specific environment. * **Throttling vs. Server Overload:** While these adjustments can help with client-side throttling, if the API server itself is overloaded, these changes might exacerbate the problem. Ensure your Kubernetes API server has sufficient resources (CPU, memory) to handle the increased load. ## How to Apply Changes These flags are typically set when deploying the KEDA operator. You will need to update the KEDA operator's deployment manifest (e.g., its `Deployment` YAML) to include these flags in the `args` section of the operator container. **Example (partial Deployment YAML):** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: keda-operator namespace: keda # Or your KEDA installation namespace spec: template: spec: containers: - name: keda-operator # Or keda-metrics-apiserver, depending on which component is throttled args: - "--kube-api-qps=40" - "--kube-api-burst=60" env: - name: KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES value: "10" # ... other existing arguments for the KEDA operator ``` ## Status Update Optimization As of recent versions of KEDA, the operator includes built-in optimizations to reduce unnecessary ScaledObject status updates. The operator now: - **Compares condition states**: Before updating status, KEDA compares the new conditions (Type, Status, Reason, and Message) with existing ones - **Skips redundant updates**: Status updates are only performed when conditions have actually changed - **Handles edge cases**: Properly distinguishes between empty condition sets and initialized conditions with 'Unknown' status This optimization is particularly beneficial in environments with many ScaledObjects, as it can significantly reduce the number of API calls made by the KEDA operator, helping to prevent API server throttling issues described above. For the most up-to-date information about this optimization, refer to the [KEDA CHANGELOG](https://github.com/kedacore/keda/blob/main/CHANGELOG.md). ## Expected Impact With proper configuration and built-in optimizations, users typically experience: - **Reduced throttling messages**: Fewer "client-side throttling" warnings in KEDA operator logs - **Lower API server load**: Decreased request volume from KEDA operations to the Kubernetes API server - **Improved performance**: Better responsiveness in environments with 100+ ScaledObjects - **More stable scaling**: Consistent autoscaling behavior without throttling-related delays ## Additional Troubleshooting By carefully tuning these parameters and leveraging KEDA's built-in optimizations, you should be able to reduce or eliminate the client-side throttling experienced by the KEDA operator. If throttling persists even after these adjustments, consider: - Further investigation into the API server's capacity and resource allocation - Reviewing your ScaledObject configurations for potential optimizations - Consulting the KEDA community for environment-specific guidance If issues continue, potential code-level optimizations within KEDA might be necessary, and feedback to the KEDA project maintainers would be valuable. ================================================ FILE: content/troubleshooting/_index.md ================================================ --- # Suppress the missing layout warning, pages are only rendered via troubleshooting shortcode. build: render: false --- ================================================ FILE: content/troubleshooting/aws-keda-operator-iam.md ================================================ +++ title = "Why does KEDA operator error with NoCredentialProviders" +++ If you are running KEDA on AWS using IRSA or KIAM for pod identity and seeing the following error messages: ``` Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal KEDAScalersStarted 31s keda-operator Started scalers watch Normal KEDAScaleTargetDeactivated 31s keda-operator Deactivated apps/v1.Deployment default/my-event-based-deployment from 1 to 0 Normal ScaledObjectReady 13s (x2 over 31s) keda-operator ScaledObject is ready for scaling Warning KEDAScalerFailed 1s (x2 over 31s) keda-operator NoCredentialProviders: no valid providers in chain. Deprecated. For verbose messaging see aws.Config.CredentialsChainVerboseErrors ``` And the operator logs: ``` 2021-11-02T23:50:29.688Z ERROR controller Reconciler error {"reconcilerGroup": "keda.sh", "reconcilerKind": "ScaledObject", "controller": "scaledobject", "name": "my-event-based-deployment-scaledobject", "namespace": "default" , "error": "error getting scaler for trigger #0: error parsing SQS queue metadata: awsAccessKeyID not found"} ``` This means hat the KEDA operator is not receiving valid credentials, even before attempting to assume the IAM role associated with the `scaleTargetRef`. Some things to check: - Ensure the `keda-operator` deployment has the `iam.amazonaws.com/role` annotation under `deployment.spec.template.metadata` not `deployment.metadata` - if using KIAM - Ensure the `keda-operator` serviceAccount is annotated `eks.amazonaws.com/role-arn` - if using IRSA - Check `kiam-server` logs, successful provisioning of credentials looks like: `kube-system kiam-server-6bb67587bd-2f47p kiam-server {"level":"info","msg":"found role","pod.iam.role":"arn:aws:iam::1234567890:role/my-service-role","pod.ip":"100.64.7.52","time":"2021-11-05T03:13:34Z"}`. - Use `grep` to filter the `kiam-server` logs, searching for the `keda-operator` pod ip. ================================================ FILE: content/troubleshooting/context-deadline-exceeded.md ================================================ +++ title = "Context Deadline Exceeded when `kubectl apply`?" weight = 2 +++ If you're encountering the following error when trying to apply a `ScaledObject` using the `kubectl apply` command: ```sh kubectl apply -f nginx-scaledobject.yaml ``` And receive an error like: `Error from server (Timeout): error when applying patch:` `{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"keda.sh/v1alpha1\",\"kind\":\"ScaledObject\",\"metadata\":{\"annotations\":{},\"name\":\"nginx-scaledobject\",\"namespace\":\"default\"},\"spec\":{\"cooldownPeriod\":300,\"maxReplicaCount\":2,\"minReplicaCount\":1,\"pollingInterval\":3,\"scaleTargetRef\":{\"name\":\"nginx-deploy\"},\"triggers\":[{\"metadata\":{\"type\":\"Utilization\",\"value\":\"90\"},\"type\":\"cpu\"}]}}\n"}},"spec":{"maxReplicaCount":2}}` `to:` `Resource: "keda.sh/v1alpha1, Resource=scaledobjects", GroupVersionKind: "keda.sh/v1alpha1, Kind=ScaledObject"` `Name: "nginx-scaledobject", Namespace: "default"` `for: "nginx-scaledobject.yaml": error when patching "nginx-scaledobject.yaml": Timeout: request did not complete within requested timeout - context deadline exceeded`. ### Root cause This issue commonly occurs when the KEDA admission webhook is not reachable by the Kubernetes control plane due to a network connectivity issue, typically on port 9443, which the webhook listens on. ### Solution (For Managed Kubernetes Services) __Step 1__: Enable Debug Logging on the Webhook This helps confirm whether the request is reaching the webhook. __Option A__: If KEDA was installed via Helm: Update your values.yaml file: ```sh webhooks: level: debug ``` Then upgrade your Helm release: ```sh helm upgrade kedacore/keda -n keda -f values.yaml ``` __Option B__: If KEDA was installed manually (without Helm): Edit the webhook deployment: ```sh kubectl edit deployment keda-admission-webhooks -n keda ``` Add or update the arguments to include: ```sh args: - "--zap-log-level=debug" ``` __Step 2__: Check Webhook Logs To confirm if the webhook is receiving the request: ```sh kubectl logs -l app=keda-admission-webhooks -n keda ``` If no logs appear when you run `kubectl apply`, it means the webhook pod is not being reached. __Step 3__: Check Network Connectivity Ensure port 9443 is open between: - The Kubernetes control plane (where `kubectl apply` runs) - The nodes hosting the `keda-admission-webhooks` pod This often involves configuring firewall rules or security groups to allow traffic from the control plane IP range to the node IP range on port 9443. ### Final Test: After opening port `9443`, try applying your ScaledObject again: ```sh kubectl apply -f nginx-scaledobject.yaml ``` If the webhook logs now show activity and the resource is created or properly rejected, the issue is resolved. ================================================ FILE: content/troubleshooting/gke-external-metrics.md ================================================ +++ title = "Why does Google Kubernetes Engine (GKE) 1.16 fail to fetch external metrics?" +++ If you are running Google Kubernetes Engine (GKE) version 1.16, and are receiving the following error: ``` unable to fetch metrics from external metrics API: .external.metrics.k8s.io is forbidden: User "system:vpa-recommender" cannot list resource "" in API group "external.metrics.k8s.io" in the namespace "": RBAC: clusterrole.rbac.authorization.k8s.io "external-metrics-reader" not found ``` You are almost certainly running into a [known issue](https://issuetracker.google.com/issues/160597676). The workaround is to recreate the `external-metrics-reader` role using the following YAML: ``` apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: external-metrics-reader rules: - apiGroups: - "external.metrics.k8s.io" resources: - "*" verbs: - list - get - watch ``` The GKE team is currently working on a fix that they expect to have out in version >= 1.16.13. ================================================ FILE: content/troubleshooting/helm-upgrade-crd.md ================================================ +++ title = "Why is Helm not able to upgrade to v2.2.1 or above?" +++ Our initial approach to manage CRDs through Helm was not ideal given it didn't update existing CRDs. This is a [known limitation of Helm](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#install-a-crd-declaration-before-using-the-resource): > There is no support at this time for upgrading or deleting CRDs using Helm. This was an explicit decision after much community discussion due to the danger for unintentional data loss. Furthermore, there is currently no community consensus around how to handle CRDs and their lifecycle. As this evolves, Helm will add support for those use cases. As of [v2.2.1](https://github.com/kedacore/charts/releases/tag/v2.2.1) of our Helm chart, we have changed our approach so that we automatically managing the CRDs through our Helm chart. Due to this transition, it can cause upgrade failures if you started using KEDA before v2.2.1 and will cause errors during upgrades such as the following: > Error: UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: CustomResourceDefinition "scaledobjects.keda.sh" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "keda"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "keda" In order to fix this, you will need to manually add the following attributes to our CRDs: - `app.kubernetes.io/managed-by: Helm` label - `meta.helm.sh/release-name: keda` annotation - `meta.helm.sh/release-namespace: keda` annotation Future upgrades should work seamlessly. ================================================ FILE: content/troubleshooting/istio-keda-faileddiscoverycheck.md ================================================ +++ title = "Why is KEDA API metrics server failing when Istio is installed?" +++ While setting up KEDA, you get an error: `(v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck` and you have [Istio](https://istio.io/) installed as service mesh in your cluster. This can lead to side effects like not being able to delete namespaces in your cluster. You will see an error like: `NamespaceDeletionDiscoveryFailure - Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: the server is currently unable to handle the request` ### Check the setup In the following we assume that KEDA is installed in the namespace `keda`. #### Check the KEDA API service status Find the api service name for the service `keda/keda-metrics-apiserver`: ```sh kubectl get apiservice --all-namespaces ``` Check for the status of the api service found in previous step: ```sh kubectl get apiservice -o yaml ``` Example: ```sh kubectl get apiservice v1beta1.external.metrics.k8s.io -o yaml ``` If the status is `False`, then there seems to be an issue with the KEDA installation. #### Check Istio installation Check if Istio is installed in your cluster: ```sh kubectl get svc -n istio-system ``` If Istio is installed you get a result like: ```sh NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 100.65.18.245 34.159.50.243 15021:31585/TCP,80:31669/TCP,443:30464/TCP 3d istiod ClusterIP 100.65.146.141 15010/TCP,15012/TCP,443/TCP,15014/TCP 3d ``` #### Check KEDA namespace labels Check the KEDA namespace labels: ```sh kubectl describe ns keda ``` If Istio injection is enabled there is **no** label stating `istio-injection=disabled`. In this setup the sidecar injection of Istio prevents the api service of KEDA to work properly. ### Solution To prevent the side-car injection of Istio we must label the namespace accordingly. This can be achieved via setting the label `istio-injection=disabled` to the namespace: ```sh kubectl label namespace keda istio-injection=disabled ``` Check that the label is set via `kubectl describe ns keda` Install KEDA into the namespace `keda` and re-check the status of the api service which should now have the status `True`. ================================================ FILE: content/troubleshooting/keda-external-metrics-issue.md ================================================ +++ title = "Kubernetes Control plane is unable to communicate to Metric server?" weight = 1 +++ If while setting up KEDA, you get an error: `(v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck` with a message: `failing or missing response from https://POD-IP:6443/apis/external.metrics.k8s.io/v1beta1: Get "https://POD-IP:6443/apis/external.metrics.k8s.io/v1beta1": Address is not allowed`. One of the reason for this can be due to CNI like Cilium or any other. ### Before you start - Make sure no network policies are blocking traffic and required CIDR's are added ### Check the status: Find the api service name for the service `keda/keda-metrics-apiserver`: ```sh kubectl get apiservice --all-namespaces ``` Check for the status of the api service found in previous step: ```sh kubectl get apiservice -o yaml ``` Example: ```sh kubectl get apiservice v1beta1.external.metrics.k8s.io -o yaml ``` If the status is `False`, then there seems to be an issue and network might be the primary reason for it. ### Solution for managed Kubernetes services: In managed Kubernetes services you might solve the issue by updating deployment file of metric-apiserver as below. ```yaml dnsPolicy: ClusterFirst hostNetwork: true ``` Eg: [Modify](https://github.com/kedacore/charts/blob/f70e45e9a21e46036d51f8e16c2c63a7de8eea1b/keda/values.yaml#L42) useHostNetwork in values file. ================================================ FILE: content/troubleshooting/profiling-keda-components.md ================================================ +++ title = "Troubleshoot KEDA errors using profiling" +++ In Golang we have the possibility to profile specific actions in order to determine what causes an issue. For example, if our `keda-operator` pod is keeps getting OOM after a specific time, using profilig we can profile the heap and see what operatios taking all of this space. Golang support many profiling options like heap, cpu, goroutines and more... (for more info check this site https://pkg.go.dev/net/http/pprof). In KEDA we provide the option to enable profiling on each component separately by enabling it using the Helm chart and providing a port (if not enabled then it won't work). ```yaml profiling: operator: enabled: false port: 8082 metricsServer: enabled: false port: 8083 webhooks: enabled: false port: 8084 ``` If not using the Helm chart then you can enable the profiling on each on of components by specifying the following argument in the respective container ```bash --profiling-bind-address=":8082" ``` and it will be exposed on the port you specified. After enabling it you can port-forward or expose the service and use tool like go tool pprof in order to get profiling data. For more info look at this document https://go.dev/blog/pprof. ================================================ FILE: content/troubleshooting/proxy-network.md ================================================ +++ title = "Why is Kubernetes unable to get metrics from KEDA?" weight = 1 +++ If while setting up KEDA, you get an error: `(v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck` with a message: `no response from https://ip:443: Get https://ip:443: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`. One of the reason for this can be that you are behind a proxy network. ### Before you start - Make sure no network policies are blocking traffic ### Check the status Find the api service name for the service `keda/keda-metrics-apiserver`: ```sh kubectl get apiservice --all-namespaces ``` Check for the status of the api service found in previous step: ```sh kubectl get apiservice -o yaml ``` Example: ```sh kubectl get apiservice v1beta1.external.metrics.k8s.io -o yaml ``` If the status is `False`, then there seems to be an issue and proxy network might be the primary reason for it. ### Solution for self-managed Kubernetes cluster Find the cluster IP for the `keda-metrics-apiserver` and `keda-operator-metrics`: ```sh kubectl get services --all-namespaces ``` In the `/etc/kubernetes/manifests/kube-apiserver.yaml` - add the cluster IPs found in the previous step in no_proxy variable. Reload systemd manager configuration: ```sh sudo systemctl daemon-reload ``` Restart kubelet: ```sh sudo systemctl restart kubelet ``` Check the API service status and the pods now. Should work! ### Solution for managed Kubernetes services In managed Kubernetes services you might solve the issue by updating firewall rules in your cluster. #### Google Kubernetes Engine (GKE) E.g. in GKE private cluster [add](https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules) port 6443 (kube-apiserver) to allowed ports in master node firewall rules. Also, if you are using Network Policies in your `kube-system` namespace, make sure they don't block access for the konnectivity agent via port 6443. You can read more about [konnectivity service](https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/#konnectivity-service). In that case, you need to add a similar NetworkPolicy in the `kube-system` namespace: ```yaml --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress-from-konnectivity-agent-to-keda namespace: kube-system spec: egress: - ports: - port: 6443 protocol: TCP to: - ipBlock: cidr: ${KUBE_POD_IP_CIDR} podSelector: matchLabels: k8s-app: konnectivity-agent policyTypes: - Egress ``` #### Amazon Elastic Kubernetes Service (EKS) E.g. Make sure the Cluster Security group can reach the Nodegroups on TCP 6443. For example, using the [terraform eks module](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest), this is achievable through the addtional nodegroup rules ```terraform module "eks" { source = "terraform-aws-modules/eks/aws" version = "19.5.1" ... create_node_security_group = true node_security_group_additional_rules = { keda_metrics_server_access = { description = "Cluster access to keda metrics" protocol = "tcp" from_port = 6443 to_port = 6443 type = "ingress" source_cluster_security_group = true } } ``` As of version `19.6.0` of the `terraform-aws-modules/eks/aws` module it is enough to have `node_security_group_enable_recommended_rules` option enabled(default) to get neccessary security group ingress rule. ================================================ FILE: content/troubleshooting/scaledobject-not-scale.md ================================================ +++ title = "Why is my `ScaledObject` paused?" weight = 1 +++ When KEDA has upstream errors to get scaler source information it will keep the current instance count of the workload unless the `fallback` section is defined. This behavior might feel like the autoscaling is not happening, but in reality, it is because of problems related to the scaler source. You can check if this is your case by reviewing the logs from the KEDA pods where you should see errors in both our Operator and Metrics server. You can also check a status of the ScaledObject (`READY` and `ACTIVE` condition) by running following command: ```bash $ kubectl get scaledobject MY-SCALED-OBJECT ``` ================================================ FILE: content/videos.md ================================================ +++ title = "Videos" description = "Videos about using KEDA" +++ ## KEDA: Unlocking Advanced Event-Driven Scaling for Kubernetes (KubeCon Europe 2025) {{< youtube id="317rLOIKfDQ" >}} ## Scaling New Heights with KEDA: Performance, Extensions, and Beyond (KubeCon Europe 2024) {{< youtube id="_5_njiPr5vg" >}} ## Exploring KEDA's Graduation and Advancements in Event-Driven Scaling (KubeCon North America 2023) {{< youtube id="wYQ2cvSj6os" >}} ### Unlocking the Potential of KEDA: New Features and Best Practices (KubeCon Europe 2023) {{< youtube id="Db3UcxXbsvw" >}} ### Real Time And Serverless Scaling In Kubernetes (KubeCon North America 2022) {{< youtube id="vjKLbfEZ7MU" >}} ================================================ FILE: data/faq.toml ================================================ [[qna]] q = "What is KEDA and why is it useful?" a = "KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources." [[qna]] q = "What are the prerequisites for using KEDA?" a = """ KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA releases are tested against specific Kubernetes versions. Refer to the documentation for the tested versions for your KEDA release. KEDA uses a CRD (custom resource definition) and the Kubernetes metric server, so you will need a Kubernetes version that supports these components. """ [[qna]] q = "Does KEDA depend on any Azure service?" a = "No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure." [[qna]] q = "Does KEDA only work with Azure Functions?" a = "No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container." [[qna]] q = "Why should we use KEDA if we are already using Azure Functions in Azure?" a = """ There are a few reasons for this: * Run functions on-premises (potentially in something like an 'intelligent edge' architecture) * Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.) * Run functions outside of Azure (no vendor lock-in) * Specific need for more control (GPU enabled compute clusters, policies, etc.) """ [[qna]] q = "Can I scale my HTTP container or function with KEDA and Kubernetes?" a = """ KEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads. We recommend using the [Prometheus scaler](/scalers/prometheus/) to create scale rule based on metrics around HTTP events for now. Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more. """ [[qna]] q = "Where can I get to the code for the Scalers?" a = "All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers)." [[qna]] q = "Is short polling intervals a problem?" a = "Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA." [[qna]] q = "How can I get involved?" a = """ There are several ways to get involved. * Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted) * We are always looking to add more scalers. * We are always looking for more samples, documentation, etc. * Please join us in our [weekly standup](https://github.com/kedacore/keda#community). """ [[qna]] q = "Can KEDA be used in production?" a = "Yes! KEDA is now 1.0 and suited for production workloads." [[qna]] q = "What does it cost?" a = "There is no charge for using KEDA itself." [[qna]] q = "How do I access KEDA resources using `client-go`?" a = """ KEDA resources can be accessed using the [dynamic client](https://godoc.org/k8s.io/client-go/dynamic) from the `client-go` package. The dynamic client's `Resource()` method accepts a [GroupVersionResource](https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionResource) describing the type of resource to be accessed and returns a [NamespaceableResourceInterface](https://godoc.org/k8s.io/client-go/dynamic#NamespaceableResourceInterface) which contains methods to retrieve, create, or manipulate that resource. Here's a code sample containing a function that retrieves a KEDA `ScaledObject` resource by name. ```go package main import ( "fmt" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/client-go/dynamic" _ "k8s.io/client-go/plugin/pkg/client/auth/gcp" "k8s.io/client-go/tools/clientcmd" "os" ) var ( kedaGVR = schema.GroupVersionResource{ Group: "keda.k8s.io", Version: "v1alpha1", Resource: "scaledobjects", } ) func GetScaledObjectByName(name string) { config, err := clientcmd.BuildConfigFromFlags("", os.Getenv("HOME")+"/.kube/config") dynClient, err := dynamic.NewForConfig(config) if err != nil { panic(err) } scaledObjectClient := dynClient.Resource(kedaGVR) scaledObject, err := scaledObjectClient.Namespace("default").Get(name, metav1.GetOptions{}) if err != nil { fmt.Printf("Error retrieving scaledobjects: %s\n", err) } else { fmt.Printf("Got ScaledObject:\n %v", scaledObject) } } ``` """ ================================================ FILE: data/faq20.toml ================================================ [[qna]] q = "What is KEDA and why is it useful?" a = "KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources." type = "General" [[qna]] q = "What are the prerequisites for using KEDA?" a = """ KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release. It uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these. > 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running. """ type = "General" [[qna]] q = "Can KEDA be used in production?" a = "Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well.." type = "General" [[qna]] q = "What does it cost?" a = "There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible." type = "General" [[qna]] q = "Can I scale HTTP workloads with KEDA and Kubernetes?" a = """ KEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box. We do, however, provide some alternative approaches: - Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on)) - Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more. """ type = "Features" [[qna]] q = "Is short polling intervals a problem?" a = "Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA." type = "Features" [[qna]] q = "Using multiple triggers for the same scale target" a = """ KEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`. By doing this, your autoscaling becomes better: - All your autoscaling rules are in one place - You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other KEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to. """ type = "Best Practices" [[qna]] q = "Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)" a = """ We recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload. They will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior. If you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead. """ type = "Best Practices" [[qna]] q = "What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?" a = """ The target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions. The current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works. By default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers). """ type = "Kubernetes" [[qna]] q = "Why does KEDA use external metrics and not custom metrics instead?" a = """ Kubernetes allows you to autoscale based on custom & external metrics which are fundamentally different: - **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus) - **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.) Because KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics. This is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality. Read [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more. """ type = "Kubernetes" [[qna]] q = "Can I run multiple metric servers serving external metrics in the same cluster?" a = """ Unfortunately, you cannot do that. Kubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics. If you want to know what external metric server is currently registered, you can use the following command: ```shell ~ kubectl get APIService/v1beta1.external.metrics.k8s.io NAME SERVICE AVAILABLE AGE v1beta1.external.metrics.k8s.io keda-system/keda-operator-metrics-apiserver True 457d ``` Once a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored. There is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet. """ type = "Kubernetes" [[qna]] q = "Can I run multiple installations of KEDA in the same cluster?" a = """ Unfortunately, you cannot do that. This is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics. Also, KEDA does not allow you to share a single metric server across multiple operator installations. Learn more in the "Can I run multiple metric servers serving external metrics in the same cluster?" FAQ entry. """ type = "Kubernetes" [[qna]] q = "How can I get involved?" a = """ There are several ways to get involved. * Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted) * We are always looking to add more scalers. * We are always looking for more samples, documentation, etc. * Please join us in our [weekly standup](https://github.com/kedacore/keda#community). """ type = "Community" [[qna]] q = "Where can I get to the code for the Scalers?" a = "All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers)." type = "Community" [[qna]] q = "How do I access KEDA resources using `client-go`?" a = """KEDA client-go is exported as part of the KEDA repository.""" [[qna]] q = "How do I run KEDA with `readOnlyRootFilesystem=true`?" a = """ As default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention. If you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system. To overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment. To use your certificate, you need to reference it in the container `args` section, e.g.: ``` args: - '--client-ca-file=/cabundle/service-ca.crt' - '--tls-cert-file=/certs/tls.crt' - '--tls-private-key-file=/certs/tls.key' ``` It is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where, by default, metrics server writes its generated cert. The corresponding helm command is: ``` helm install keda kedacore/keda --namespace keda \ --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \ --set 'securityContext.metricServer.readOnlyRootFilesystem=true' ``` """ type = "Features" [[qna]] q = "How do I run KEDA with TLS v1.3 only?" a = """ By default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites. In some environments, these ciphers may be considered less secure, for example CBC ciphers. As an alternative, you can configure the minimum TLS version to be v1.3 to increase security. Since all modern clients support this version, there should be no impact in most scenarios. You can set this with args - e.g.: ``` args: - '--tls-min-version=VersionTLS13' ``` """ type = "Features" [[qna]] q = "Does KEDA depend on any Azure service?" a = "No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure." type = "Azure" [[qna]] q = "Does KEDA only work with Azure Functions?" a = "No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container." type = "Azure" [[qna]] q = "Why should we use KEDA if we are already using Azure Functions in Azure?" a = """ There are a few reasons for this: * Run functions on-premises (potentially in something like an 'intelligent edge' architecture) * Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.) * Run functions outside of Azure (no vendor lock-in) * Specific need for more control (GPU enabled compute clusters, policies, etc.) """ type = "Azure" [[qna]] q = "Does scaler search support wildcard search?" a = "Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query." type = "Website" ================================================ FILE: data/faq2_14.toml ================================================ [[qna]] q = "What is KEDA and why is it useful?" a = "KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources." type = "General" [[qna]] q = "What are the prerequisites for using KEDA?" a = """ KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release. It uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these. > 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running. """ type = "General" [[qna]] q = "Can KEDA be used in production?" a = "Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well.." type = "General" [[qna]] q = "What does it cost?" a = "There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible." type = "General" [[qna]] q = "Can I scale HTTP workloads with KEDA and Kubernetes?" a = """ KEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box. We do, however, provide some alternative approaches: - Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on)) - Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more. """ type = "Features" [[qna]] q = "Is short polling intervals a problem?" a = "Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA." type = "Features" [[qna]] q = "Using multiple triggers for the same scale target" a = """ KEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`. By doing this, your autoscaling becomes better: - All your autoscaling rules are in one place - You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other KEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to. """ type = "Best Practices" [[qna]] q = "Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)" a = """ We recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload. They will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior. If you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead. """ type = "Best Practices" [[qna]] q = "What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?" a = """ The target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions. The current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works. By default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers). """ type = "Kubernetes" [[qna]] q = "Why does KEDA use external metrics and not custom metrics instead?" a = """ Kubernetes allows you to autoscale based on custom & external metrics which are fundamentally different: - **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus) - **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.) Because KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics. This is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality. Read [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more. """ type = "Kubernetes" [[qna]] q = "Can I run multiple metric servers serving external metrics in the same cluster?" a = """ Unfortunately, you cannot do that. Kubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics. If you want to know what external metric server is currently registered, you can use the following command: ```shell ~ kubectl get APIService/v1beta1.external.metrics.k8s.io NAME SERVICE AVAILABLE AGE v1beta1.external.metrics.k8s.io keda-system/keda-operator-metrics-apiserver True 457d ``` Once a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored. There is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet. """ type = "Kubernetes" [[qna]] q = "Can I run multiple installations of KEDA in the same cluster?" a = """ Unfortunately, you cannot do that. This is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics. Also, KEDA does not allow you to share a single metric server across multiple operator installations. Learn more in the "Can I run multiple metric servers serving external metrics in the same cluster?" FAQ entry. """ type = "Kubernetes" [[qna]] q = "How can I get involved?" a = """ There are several ways to get involved. * Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted) * We are always looking to add more scalers. * We are always looking for more samples, documentation, etc. * Please join us in our [weekly standup](https://github.com/kedacore/keda#community). """ type = "Community" [[qna]] q = "Where can I get to the code for the Scalers?" a = "All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers)." type = "Community" [[qna]] q = "How do I access KEDA resources using `client-go`?" a = """KEDA client-go is exported as part of the KEDA repository.""" [[qna]] q = "How do I run KEDA with `readOnlyRootFilesystem=true`?" a = """ As default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention. If you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system. To overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment. To use your certificate, you need to reference it in the container `args` section, e.g.: ``` args: - '--client-ca-file=/cabundle/service-ca.crt' - '--tls-cert-file=/certs/tls.crt' - '--tls-private-key-file=/certs/tls.key' ``` It is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where, by default, metrics server writes its generated cert. The corresponding helm command is: ``` helm install keda kedacore/keda --namespace keda \ --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \ --set 'securityContext.metricServer.readOnlyRootFilesystem=true' ``` """ type = "Features" [[qna]] q = "How do I run KEDA with TLS v1.3 only?" a = """ By default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites. In some environments, these ciphers may be considered less secure, for example CBC ciphers. As an alternative, you can configure the minimum TLS version to be v1.3 to increase security. Since all modern clients support this version, there should be no impact in most scenarios. You can set this with args - e.g.: ``` args: - '--tls-min-version=VersionTLS13' ``` """ type = "Features" [[qna]] q = "Does KEDA depend on any Azure service?" a = "No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure." type = "Azure" [[qna]] q = "Does KEDA only work with Azure Functions?" a = "No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container." type = "Azure" [[qna]] q = "Why should we use KEDA if we are already using Azure Functions in Azure?" a = """ There are a few reasons for this: * Run functions on-premises (potentially in something like an 'intelligent edge' architecture) * Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.) * Run functions outside of Azure (no vendor lock-in) * Specific need for more control (GPU enabled compute clusters, policies, etc.) """ type = "Azure" [[qna]] q = "Does scaler search support wildcard search?" a = "Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query." type = "Website" ================================================ FILE: data/faq2_15.toml ================================================ [[qna]] q = "What is KEDA and why is it useful?" a = "KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources." type = "General" [[qna]] q = "What are the prerequisites for using KEDA?" a = """ KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release. It uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these. > 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running. """ type = "General" [[qna]] q = "Can KEDA be used in production?" a = "Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well.." type = "General" [[qna]] q = "What does it cost?" a = "There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible." type = "General" [[qna]] q = "Can I scale HTTP workloads with KEDA and Kubernetes?" a = """ KEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box. We do, however, provide some alternative approaches: - Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on)) - Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more. """ type = "Features" [[qna]] q = "Is short polling intervals a problem?" a = "Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA." type = "Features" [[qna]] q = "Using multiple triggers for the same scale target" a = """ KEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`. By doing this, your autoscaling becomes better: - All your autoscaling rules are in one place - You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other KEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to. """ type = "Best Practices" [[qna]] q = "Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)" a = """ We recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload. They will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior. If you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead. """ type = "Best Practices" [[qna]] q = "What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?" a = """ The target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions. The current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works. By default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers). """ type = "Kubernetes" [[qna]] q = "Why does KEDA use external metrics and not custom metrics instead?" a = """ Kubernetes allows you to autoscale based on custom & external metrics which are fundamentally different: - **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus) - **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.) Because KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics. This is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality. Read [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more. """ type = "Kubernetes" [[qna]] q = "Can I run multiple metric servers serving external metrics in the same cluster?" a = """ Unfortunately, you cannot do that. Kubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics. If you want to know what external metric server is currently registered, you can use the following command: ```shell ~ kubectl get APIService/v1beta1.external.metrics.k8s.io NAME SERVICE AVAILABLE AGE v1beta1.external.metrics.k8s.io keda-system/keda-operator-metrics-apiserver True 457d ``` Once a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored. There is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet. """ type = "Kubernetes" [[qna]] q = "Can I run multiple installations of KEDA in the same cluster?" a = """ Unfortunately, you cannot do that. This is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics. Also, KEDA does not allow you to share a single metric server across multiple operator installations. Learn more in the "Can I run multiple metric servers serving external metrics in the same cluster?" FAQ entry. """ type = "Kubernetes" [[qna]] q = "How can I get involved?" a = """ There are several ways to get involved. * Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted) * We are always looking to add more scalers. * We are always looking for more samples, documentation, etc. * Please join us in our [weekly standup](https://github.com/kedacore/keda#community). """ type = "Community" [[qna]] q = "Where can I get to the code for the Scalers?" a = "All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers)." type = "Community" [[qna]] q = "How do I access KEDA resources using `client-go`?" a = """KEDA client-go is exported as part of the KEDA repository.""" [[qna]] q = "How do I run KEDA with `readOnlyRootFilesystem=true`?" a = """ As default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention. If you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system. To overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment. To use your certificate, you need to reference it in the container `args` section, e.g.: ``` args: - '--client-ca-file=/cabundle/service-ca.crt' - '--tls-cert-file=/certs/tls.crt' - '--tls-private-key-file=/certs/tls.key' ``` It is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where, by default, metrics server writes its generated cert. The corresponding helm command is: ``` helm install keda kedacore/keda --namespace keda \ --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \ --set 'securityContext.metricServer.readOnlyRootFilesystem=true' ``` """ type = "Features" [[qna]] q = "How do I run KEDA with TLS v1.3 only?" a = """ By default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites. In some environments, these ciphers may be considered less secure, for example CBC ciphers. As an alternative, you can configure the minimum TLS version to be v1.3 to increase security. Since all modern clients support this version, there should be no impact in most scenarios. You can set this with args - e.g.: ``` args: - '--tls-min-version=VersionTLS13' ``` """ type = "Features" [[qna]] q = "Does KEDA depend on any Azure service?" a = "No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure." type = "Azure" [[qna]] q = "Does KEDA only work with Azure Functions?" a = "No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container." type = "Azure" [[qna]] q = "Why should we use KEDA if we are already using Azure Functions in Azure?" a = """ There are a few reasons for this: * Run functions on-premises (potentially in something like an 'intelligent edge' architecture) * Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.) * Run functions outside of Azure (no vendor lock-in) * Specific need for more control (GPU enabled compute clusters, policies, etc.) """ type = "Azure" [[qna]] q = "Does scaler search support wildcard search?" a = "Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query." type = "Website" ================================================ FILE: data/faq2_19.toml ================================================ [[qna]] q = "What is KEDA and why is it useful?" a = "KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources." type = "General" [[qna]] q = "What are the prerequisites for using KEDA?" a = """ KEDA is community-supported. For all support options, see the [Support](/support/) page. KEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release. It uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these. > 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running. """ type = "General" [[qna]] q = "Can KEDA be used in production?" a = "Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well.." type = "General" [[qna]] q = "What does it cost?" a = "There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible." type = "General" [[qna]] q = "Can I scale HTTP workloads with KEDA and Kubernetes?" a = """ KEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box. We do, however, provide some alternative approaches: - Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on)) - Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more. """ type = "Features" [[qna]] q = "Is short polling intervals a problem?" a = "Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA." type = "Features" [[qna]] q = "Using multiple triggers for the same scale target" a = """ KEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`. By doing this, your autoscaling becomes better: - All your autoscaling rules are in one place - You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other KEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to. """ type = "Best Practices" [[qna]] q = "Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)" a = """ We recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload. They will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior. If you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead. """ type = "Best Practices" [[qna]] q = "What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?" a = """ The target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions. The current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works. By default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers). """ type = "Kubernetes" [[qna]] q = "Why does KEDA use external metrics and not custom metrics instead?" a = """ Kubernetes allows you to autoscale based on custom & external metrics which are fundamentally different: - **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus) - **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.) Because KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics. This is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality. Read [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more. """ type = "Kubernetes" [[qna]] q = "Can I run multiple metric servers serving external metrics in the same cluster?" a = """ Unfortunately, you cannot do that. Kubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics. If you want to know what external metric server is currently registered, you can use the following command: ```shell ~ kubectl get APIService/v1beta1.external.metrics.k8s.io NAME SERVICE AVAILABLE AGE v1beta1.external.metrics.k8s.io keda-system/keda-operator-metrics-apiserver True 457d ``` Once a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored. There is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet. """ type = "Kubernetes" [[qna]] q = "Can I run multiple installations of KEDA in the same cluster?" a = """ Unfortunately, you cannot do that. This is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics. Also, KEDA does not allow you to share a single metric server across multiple operator installations. Learn more in the "Can I run multiple metric servers serving external metrics in the same cluster?" FAQ entry. """ type = "Kubernetes" [[qna]] q = "How can I get involved?" a = """ There are several ways to get involved. * Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted) * We are always looking to add more scalers. * We are always looking for more samples, documentation, etc. * Please join us in our [weekly standup](https://github.com/kedacore/keda#community). """ type = "Community" [[qna]] q = "Where can I get to the code for the Scalers?" a = "All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers)." type = "Community" [[qna]] q = "How do I access KEDA resources using `client-go`?" a = """KEDA client-go is exported as part of the KEDA repository.""" [[qna]] q = "How do I run KEDA with `readOnlyRootFilesystem=true`?" a = """ As default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention. If you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system. To overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment. To use your certificate, you need to reference it in the container `args` section, e.g.: ``` args: - '--client-ca-file=/cabundle/service-ca.crt' - '--tls-cert-file=/certs/tls.crt' - '--tls-private-key-file=/certs/tls.key' ``` It is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where, by default, metrics server writes its generated cert. The corresponding helm command is: ``` helm install keda kedacore/keda --namespace keda \ --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \ --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \ --set 'securityContext.metricServer.readOnlyRootFilesystem=true' ``` """ type = "Features" [[qna]] q = "How do I run KEDA with TLS v1.3 only?" a = """ By default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites. In some environments, these ciphers may be considered less secure, for example CBC ciphers. As an alternative, you can configure the minimum TLS version to be v1.3 to increase security. Since all modern clients support this version, there should be no impact in most scenarios. You can set this with args - e.g.: ``` args: - '--tls-min-version=VersionTLS13' ``` """ type = "Features" [[qna]] q = "Does KEDA depend on any Azure service?" a = "No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure." type = "Azure" [[qna]] q = "Does KEDA only work with Azure Functions?" a = "No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container." type = "Azure" [[qna]] q = "Why should we use KEDA if we are already using Azure Functions in Azure?" a = """ There are a few reasons for this: * Run functions on-premises (potentially in something like an 'intelligent edge' architecture) * Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.) * Run functions outside of Azure (no vendor lock-in) * Specific need for more control (GPU enabled compute clusters, policies, etc.) """ type = "Azure" [[qna]] q = "Does scaler search support wildcard search?" a = "Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query." type = "Website" ================================================ FILE: hugo.toml ================================================ baseURL = "https://keda.sh" languageCode = "en-us" title = "KEDA" enableGitInfo = true disableKinds = ["taxonomy", "term"] [services.googleAnalytics] id = 'G-YSWMV22VTQ' # See other available styles here: https://xyproto.github.io/splash/docs/ [markup.highlight] style = "dracula" [params] # Main page hero tagline = "Kubernetes Event-driven Autoscaling" description = "Application autoscaling made simple" # "What is KEDA?" section on main page what_is = """ **KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. **KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA, you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks. """ locale = "en_US" twitter_handle = "kedaorg" favicon = "favicon.png" [params.docsearch] appId = "3IFB1FERQT" apiKey = "0e8dd1123a0df5e715fc587ee0930782" # notsecret indexName = "keda" [params.versions] docs = [ "2.19", "2.18", "2.17", "2.16", "2.15", "2.14", "2.13", "2.12", "2.11", "2.10", "2.9", "2.8", "2.7", "2.6", "2.5", "2.4", "2.3", "2.2", "2.1", "2.0", "1.5", "1.4", ] http-add-on = ["0.14"] [params.unreleased] docs = ["2.20"] http-add-on = [] # Site fonts served from @fontsource npm packages (see module mounts). # Browse available options at https://fonts.google.com. [[params.fonts]] name = "Inria Sans" sizes = [300, 400, 700] type = "sans_serif" [[params.fonts]] name = "Roboto Mono" sizes = [300, 400, 600, 700] type = "monospace" # All logos are in static/img/logos [params.logos] navbar = "keda-horizontal-color.png" hero = "keda-icon-color.png" footer = "keda-icon-white.png" [mediaTypes."text/netlify"] delimiter = "" [outputFormats.REDIRECTS] mediaType = "text/netlify" baseName = "_redirects" [outputs] home = ["HTML", "RSS", "REDIRECTS", "Lunr"] [outputFormats.Lunr] baseName = "index" isPlainText = true mediaType = "application/json" notAlternative = true # parameters for lunr search [params.lunr] vars = [ "title", "maintainer", "description", "availability", "category", "type", ] params = ["availability", "maintainer", "category", "type"] # "Highlighted Samples" section on the main page [[params.samples]] title = "RabbitMQ and Go" content = "RabbitMQ Consumer written in Go that is scaled with KEDA." url = "https://github.com/kedacore/sample-go-rabbitmq" icon = "fas fa-envelope" [[params.samples]] title = "Azure Functions and Queue" content = "Azure Function that triggers on Azure Storage Queues." url = "https://github.com/kedacore/sample-hello-world-azure-functions" icon = "fas fa-bolt" [[params.samples]] title = ".NET Core worker and Azure Service Bus" content = "Scale a .NET Core worker based on an Azure Service Bus queue." url = "https://github.com/kedacore/sample-dotnet-worker-servicebus-queue" icon = "fas fa-cloud" # Social media buttons [[params.social]] name = "Twitter" icon = "fab fa-twitter" bg_color = "twitter-blue" icon_color = "white" text_color = "white" url = "https://twitter.com/kedaorg" [[params.social]] name = "GitHub" icon = "fab fa-github" bg_color = "white" icon_color = "black" text_color = "black" url = "https://github.com/kedacore/keda" [[params.social]] name = "Slack" icon = "fab fa-slack" bg_color = "slack-green" icon_color = "white" text_color = "white" url = "https://kubernetes.slack.com/messages/CKZJ36A5D" # Main page hero buttons [[menu.buttons]] url = "/docs/concepts" name = "Concepts" pre = "fas fa-bars-staggered" weight = 1 [[menu.buttons]] url = "/docs/deploy" name = "Deploying KEDA" pre = "fas fa-circle-play" weight = 2 [[menu.buttons]] url = "/docs/concepts/#keda-architecture" name = "Architecture" pre = "fas fa-diagram-project" weight = 3 [[menu.buttons]] url = "/docs/scalers" name = "Scalers" pre = "fas fa-ruler-vertical" weight = 4 [[menu.buttons]] url = "/docs/authentication-providers" name = "Auth providers" pre = "fas fa-lock" weight = 5 [[menu.buttons]] url = "/http-add-on/" name = "HTTP Add-on" pre = "fas fa-globe" weight = 6 [[menu.buttons]] url = "/blog" name = "Blog" pre = "fas fa-rss" weight = 7 # Navbar and footer menu [[menu.docs]] url = "/docs/" name = "Docs" identifier = "docs" weight = 1 [[menu.docs]] url = "/docs/deploy" name = "Deploying KEDA" parent = "docs" weight = 1 [[menu.docs]] url = "/docs/concepts" name = "Concepts" identifier = "Concepts" parent = "docs" weight = 2 [[menu.docs]] url = "/docs/concepts/scaling-deployments/" name = "Scaling Deployments, StatefulSets & Custom Resources" parent = "Concepts" weight = 1 [[menu.docs]] url = "/docs/concepts/scaling-jobs/" name = "Scaling Jobs" parent = "Concepts" weight = 2 [[menu.docs]] url = "/docs/concepts/authentication/" name = "Authentication" parent = "Concepts" weight = 3 [[menu.docs]] url = "/docs/concepts/external-scalers/" name = "External Scalers" parent = "Concepts" weight = 4 [[menu.docs]] url = "/docs/concepts/admission-webhooks/" name = "Admission Webhooks" parent = "Concepts" weight = 5 [[menu.docs]] url = "/docs/concepts/troubleshooting/" name = "Troubleshooting" parent = "Concepts" weight = 6 [[menu.docs]] url = "/docs/concepts/#keda-architecture" name = "Architecture" parent = "docs" weight = 3 [[menu.docs]] url = "/docs/scalers" name = "Scalers" parent = "docs" weight = 4 [[menu.docs]] url = "/docs/operate/" name = "Operate" parent = "docs" weight = 5 [[menu.docs]] url = "/docs/integrations/" name = "Integrations" parent = "docs" weight = 6 [[menu.docs]] url = "/docs/authentication-providers" name = "Auth providers" parent = "docs" weight = 7 [[menu.docs]] url = "/docs/migration/" name = "Migration Guide" parent = "docs" weight = 8 [[menu.docs]] url = "/docs/reference/faq/" name = "FAQ" parent = "docs" weight = 9 [[menu.docs]] url = "/docs/troubleshooting/" name = "Troubleshooting Guide" parent = "docs" weight = 10 [[menu.docs]] url = "/http-add-on/" name = "HTTP Add-on" parent = "docs" weight = 11 [menu.docs.params] prependDivider = true [[menu.main]] url = "/blog" name = "Blog" weight = 2 [[menu.main]] name = "Community" identifier = "community" weight = 3 [[menu.main]] url = "/community/" name = "Overview" parent = "community" weight = 1 [[menu.main]] url = "/community/#get-involved" name = "Get Involved" parent = "community" weight = 2 [[menu.main]] url = "/community/#end-users" name = "End-Users" parent = "community" weight = 3 [[menu.main]] url = "/community/#partners" name = "Partners" parent = "community" weight = 4 [[menu.main]] url = "/community/#supported-by" name = "Supported by" parent = "community" weight = 5 [[menu.main]] url = "/videos/" name = "Videos" parent = "community" weight = 6 [[menu.main]] url = "https://github.com/kedacore/samples" name = "Samples" parent = "community" weight = 7 [[menu.main]] name = "Project" identifier = "project" weight = 4 [[menu.main]] url = "/support/" name = "Support" parent = "project" weight = 1 [[menu.main]] url = "https://github.com/cncf/foundation/blob/master/code-of-conduct.md" name = "Code of Conduct" parent = "project" weight = 2 [[menu.main]] url = "https://github.com/kedacore/keda/blob/main/CHANGELOG.md" name = "Changelog" parent = "project" weight = 3 [[menu.main]] url = "https://github.com/kedacore/governance/blob/main/GOVERNANCE.md" name = "Governance" parent = "project" weight = 4 [[menu.main]] url = "https://github.com/kedacore/keda/blob/main/ROADMAP.md" name = "Roadmap" parent = "project" weight = 5 [[menu.main]] url = "https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md" name = "Breaking Changes & Deprecations" parent = "project" weight = 6 [[menu.main]] url = "https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md" name = "Contributing" parent = "project" weight = 7 [[menu.main]] url = "https://github.com/kedacore/governance/blob/main/BRANDING.md" name = "Colors and Logos" parent = "project" weight = 8 [[menu.main]] url = "https://github.com/kedacore/keda/blob/main/LICENSE" name = "License" parent = "project" weight = 9 [[menu.main]] url = "https://github.com/kedacore/governance/blob/main/MEMBERS.md" name = "Maintainers" parent = "project" weight = 10 [[menu.main]] url = "/resources/" name = "Learning Resources" parent = "project" weight = 11 [[menu.main]] url = "https://store.cncf.io/collections/keda" name = "Merch" parent = "project" weight = 12 [[menu.main]] url = "/enterprise/" name = "Enterprise" weight = 5 # "Features" section on the main page [[params.features]] title = "Autoscaling Made Simple" content = "Bring rich scaling to every workload in your [Kubernetes](https://kubernetes.io) cluster" icon = "fas fa-rocket" [[params.features]] title = "Event-driven" content = "Intelligently scale your event-driven application" icon = "fas fa-bolt" [[params.features]] title = "Built-in Scalers" content = "Catalog of 70+ built-in scalers for various cloud platforms, databases, messaging systems, telemetry systems, CI/CD, and more" icon = "fas fa-cubes" [[params.features]] title = "Multiple Workload Types" content = "Support for variety of workload types such as deployments, jobs & custom resources with `/scale` sub-resource" icon = "fas fa-shapes" [[params.features]] title = "Reduce environmental impact" content = "Build sustainable platforms by optimizing workload scheduling and scale-to-zero" icon = "fas fa-seedling" [[params.features]] title = "Extensible" content = "Bring-your-own or use community-maintained scalers" icon = "fas fa-diagram-project" [[params.features]] title = "Vendor-Agnostic" content = "Support for triggers across variety of cloud providers & products" icon = "fas fa-cloud" [[params.features]] title = "Azure Functions Support" content = "Run and scale your Azure Functions on Kubernetes in production workloads" icon = "fab fa-microsoft" # "Users" section on the Community page [[params.users]] url = "https://alibabacloud.com/" logo = "alibaba-cloud.png" [[params.users]] url = "https://ampify.io/" logo = "ampify-io.png" [[params.users]] url = "https://airflow.apache.org/" logo = "apache-airflow.png" [[params.users]] url = "https://www.astronomer.io" logo = "astronomer.svg" [[params.users]] url = "https://baseten.co/" logo = "baseten.png" [[params.users]] url = "https://www.bolddesk.com/" logo = "bolddesk.svg" [[params.users]] url = "https://chattermill.com" logo = "chattermill.png" [[params.users]] url = "https://cap.energy" logo = "capenergy.png" [[params.users]] url = "https://cisco.com" logo = "cisco.svg" [[params.users]] url = "https://www.cloud-trade.com" logo = "cloud-trade.png" [[params.users]] url = "https://coralogix.com/" logo = "coralogix.gif" [[params.users]] url = "https://cyera.io" logo = "cyera.png" [[params.users]] url = "https://devtron.ai" logo = "devtron-logo.png" [[params.users]] url = "https://dig.security" logo = "digsecurity.gif" [[params.users]] url = "https://docplanner.tech" logo = "docplanner-tech.png" [[params.users]] url = "https://www.fedex.com/en-us/home.html/" logo = "fedex.png" [[params.users]] url = "https://fission.io/" logo = "fission.png" [[params.users]] url = "https://www.foresightmining.com/" logo = "foresight.png" [[params.users]] url = "https://www.freepikcompany.com/" logo = "freepik-company.png" [[params.users]] url = "https://www.grafana.com" logo = "grafana.png" [[params.users]] url = "https://www.grab.com" logo = "grab.svg" [[params.users]] url = "https://github.com/hmcts/" logo = "hmcts.png" [[params.users]] url = "https://intension.de" logo = "intension.png" [[params.users]] url = "https://www.intercept.cloud" logo = "intercept.png" [[params.users]] url = "https://kaufland-ecommerce.com" logo = "kaufland-ecommerce.png" [[params.users]] url = "https://kendaxa.com" logo = "kendaxa.png" [[params.users]] url = "https://home.kpmg/uk/en/home.html" logo = "KPMG.jpeg" [[params.users]] url = "https://www.leanix.net/" logo = "leanix.png" [[params.users]] url = "https://maus.technology/" logo = "maus-technology.png" [[params.users]] url = "https://underthehood.meltwater.com/" logo = "meltwater.png" [[params.users]] url = "https://metamaze.eu/" logo = "metamaze.png" [[params.users]] url = "https://microsoft.com" logo = "microsoft.png" [[params.users]] url = "https://www.mivation.com" logo = "mivation-inc.png" [[params.users]] url = "https://nemlig.com" logo = "nemlig.png" [[params.users]] url = "https://opsworks.co" logo = "opsworks.png" [[params.users]] url = "https://www.playstudios.com" logo = "playstudios.jpg" [[params.users]] url = "https://www.pollinate.global" logo = "pollinate.gif" [[params.users]] url = "https://www.procore.com" logo = "procore.svg" [[params.users]] url = "https://www.theproindia.com" logo = "pro-logo.svg" [[params.users]] url = "https://www.purefacts.com" logo = "purefacts.png" [[params.users]] url = "https://qonto.com" logo = "qonto.png" [[params.users]] url = "https://redhat.com" logo = "red-hat.png" [[params.users]] url = "https://www.reddit.com/" logo = "reddit.svg" [[params.users]] url = "https://www.rewe-digital.com/" logo = "rewe-digital.svg" [[params.users]] url = "https://roadwork.io" logo = "roadwork.png" [[params.users]] url = "https://www.schrederhyperion.com" logo = "schreder-hyperion.png" [[params.users]] url = "https://schwarz-digits.de/en" logo = "schwarz-digits.png" [[params.users]] url = "https://seldon.io/" logo = "seldon.png" [[params.users]] url = "https://sharry.tech/" logo = "sharry.png" [[params.users]] url = "https://stilingue.com.br" logo = "stilingue.png" [[params.users]] url = "https://www.swisslife.ch/" logo = "swisslife.jpg" [[params.users]] url = "https://www.taotesting.com" logo = "taotesting.svg" [[params.users]] url = "https://www.teamleader.eu" logo = "teamleader.png" [[params.users]] url = "https://www.unitary.ai/" logo = "unitary.png" [[params.users]] url = "https://vitc.gmbh" logo = "vitc.png" [[params.users]] url = "https://www.wakacje.pl/" logo = "wakacje.png" [[params.users]] url = "https://www.wingie.com" logo = "wingie-enuygun.png" [[params.users]] url = "https://www.workiva.com" logo = "workiva.png" [[params.users]] url = "https://www.xbox.com" logo = "xbox.png" [[params.users]] url = "https://zapier.com" logo = "zapier.png" # "Partners" section on the Community page [[params.partners]] url = "https://kedify.io/?utm_source=keda_oss_site" logo = "kedify.png" [[params.partners]] url = "https://schwarz-digits.de/en" logo = "schwarz-digits.png" # "Supported by" section on the Community page [[params.supportedby]] url = "https://azure.microsoft.com/en-us/services/devops/" logo = "azure-devops.png" [[params.supportedby]] url = "https://www.cncf.io/" logo = "cncf-color.png" [[params.supportedby]] url = "https://azure.microsoft.com/" logo = "microsoft-azure.png" [[params.supportedby]] url = "https://snyk.io" logo = "snyk.png" [[params.supportedby]] url = "https://vexxhost.com" logo = "vexxhost.png" # Enterprise page, sorted alphabetically by name of the vendor [[params.vendors]] name = "Kedify" logo = "vendors/kedify.png" description = """ Kedify is founded by the core maintainers of KEDA and offers enterprise autoscaling solutions based on KEDA, providing: - State-of-the-art scalers and features, including a **production-grade HTTP Scaler**, exclusively available in Kedify. - Support for Multi-tenant KEDA installation, Multi-Cluster scaling, Predictive and Vertical scaling, and more. - **Enterprise-grade support**, ensuring secure KEDA builds with timely updates, patches, and critical fixes. - A comprehensive **dashboard** for streamlined management and monitoring across multiple clusters. """ urls = [ { text = "Visit Kedify website for more details", url = "https://kedify.io/?utm_source=keda_oss_site" }, ] [[params.vendors]] name = "Microsoft" logo = "vendors/microsoft-azure.png" description = """ Microsoft provides multiple solutions integrated with KEDA: - **Azure Container Apps**: Allows you to deploy microservices that automatically scale based on KEDA. - **KEDA Add-On for Azure Kubernetes Service**: Plugin for straightforward installation on Azure Kubernetes Service. """ urls = [ { text = "Azure Container Apps", url = "https://docs.microsoft.com/en-us/azure/container-apps/scale-app" }, { text = "AKS KEDA Add-On", url = "https://docs.microsoft.com/en-us/azure/aks/keda-about" }, ] [[params.vendors]] name = "Red Hat" logo = "vendors/red-hat.png" description = """ Red Hat integrates KEDA with OpenShift through the **Custom Metrics Autoscaler** (CMA) available through the OpenShift Marketplace. """ urls = [ { text = "Learn more about the CMA", url = "https://cloud.redhat.com/blog/custom-metrics-autoscaler-on-openshift" }, ] [module] [[module.mounts]] source = "static" target = "static" [[module.mounts]] source = "node_modules/@fortawesome/fontawesome-free/css" target = "static/fontawesome/css" [[module.mounts]] source = "node_modules/@fortawesome/fontawesome-free/webfonts" target = "static/fontawesome/webfonts" [[module.mounts]] source = "node_modules/@fontsource/inria-sans" target = "static/fonts/inria-sans" [[module.mounts]] source = "node_modules/@fontsource/roboto-mono" target = "static/fonts/roboto-mono" [[module.mounts]] source = "node_modules/@docsearch/css/dist" target = "static/css/docsearch" ================================================ FILE: includes/get-involved.md ================================================ If you're interested in contributing to or participating in the direction of KEDA, you can join our community meetings. * Meeting time: Bi-weekly Tues 17:00 (European time - CEST/CET). (Subscribe to [Google Agenda](https://calendar.google.com/calendar?cid=bjE0bjJtNWM0MHVmam1ob2ExcTgwdXVkOThAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) | [Convert to your timezone](https://dateful.com/time-zone-converter?t=04:00%20pm&tz=UTC)) * Zoom link: https://zoom.us/j/96655859927?pwd=cGxaWWpHOVZSMEZDY3NuWWVIMERtdz09 (Password: keda) * Meeting agenda: [Google Docs](https://docs.google.com/document/d/1zdwD6j86GxcCe5S5ay9suCO77WPrEDnKSfuaI24EwM4/edit?usp=sharing) Just want to learn or chat about KEDA? Feel free to join the conversation in the [#keda](https://kubernetes.slack.com/messages/CKZJ36A5D) (general), [#keda-dev](https://kubernetes.slack.com/archives/C01JGDP8MB8) & [#keda-docs](https://kubernetes.slack.com/archives/C03M2DKCS3H) channel(s) on the [Kubernetes Slack](https://slack.k8s.io)! ================================================ FILE: layouts/404.html ================================================ {{ define "title" -}} 404 Page not found | {{ site.Title -}} {{ end }} {{ define "main" -}}

Woops! Page not found.

That's not very convenient, sorry about that! Maybe you were looking for:

Let us know

Let us know so we can fix this dead link, you can report it here.
{{ end }} ================================================ FILE: layouts/_default/_markup/render-image.html ================================================ {{ $src := .Destination | safeURL }} {{ $id := index (last 1 (split .Destination "/")) 0 | replaceRE ".png" "" }}
{{ . }}
================================================ FILE: layouts/_default/_markup/render-link.html ================================================ {{- $link := .Destination -}} {{ $isRemote := strings.HasPrefix $link "http" }} {{- if not $isRemote -}} {{ $url := urls.Parse .Destination }} {{- if $url.Path -}} {{- $fragment := "" -}} {{- with $url.Fragment }}{{ $fragment = printf "#%s" . }}{{ end -}} {{- if .Page.GetPage $url.Path }}{{ $link = printf "%s%s" (.Page.GetPage $url.Path).RelPermalink $fragment }}{{ end }}{{ end -}} {{- end -}} {{- .Text | safeHTML -}}{{ if $isRemote }}{{ end }} ================================================ FILE: layouts/_default/baseof.html ================================================ {{ partial "meta.html" . }} {{- block "title" . -}} {{ .Title }} | {{ site.Title -}} {{ end -}} {{ partial "css.html" . }} {{ partial "favicon.html" . }}
{{ partial "navbar.html" . }} {{ block "main" . }}{{ end }}
{{ partial "footer.html" . }} {{ partial "javascript.html" . }} ================================================ FILE: layouts/_default/card-info.html ================================================ {{ $desc := .Description | markdownify }} {{ $availability := .Params.availability }} {{ $maintainer := .Params.maintainer }} {{ $project := .Params.project }}
{{ .Title }}

{{ with $desc }}
{{ . }}
{{ end }}
{{ if or $availability $maintainer }}
{{ with $availability }}
Availability {{ . }}
{{ end }} {{ with $maintainer }}
Maintainer: {{ . }}
{{ end }} {{ with $project }}
Project: {{ . }}
{{ end }}
{{ end }}
================================================ FILE: layouts/_default/list.lunr.json ================================================ {{- $index := slice -}} {{- range $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" -}} {{- $index = $index | append (dict "title" $scalers.Title "version" (index (first 3 (split (delimit (split $scalers.RelPermalink "/") "," "") ",")) 2) "href" $scalers.RelPermalink "availability" $scalers.Params.availability "description" ($scalers.Params.description) "maintainer" $scalers.Params.maintainer "category" $scalers.Params.category "type" "built-in" ) -}} {{- end -}} {{- $index | jsonify -}} ================================================ FILE: layouts/_default/single.html ================================================ {{ define "main" }} {{ partial "hero.html" . }} {{ partial "content.html" . }} {{ end }} ================================================ FILE: layouts/_default/sitemap.xml ================================================ {{- /* sitemap.xml should only contain canonical urls. */ -}} {{- /* For versioned pages, the canonical is the current version and it's the only version we should include */ -}} {{- /* For blog and other pages, we can include all of them as they aren't versioned */ -}} {{ $docsLatest := index site.Params.versions.docs 0 -}} {{ printf "" | safeHTML }} {{ range .Data.Pages }} {{- if and .Permalink (or (and (strings.Contains .Permalink "docs/") (strings.Contains .Permalink $docsLatest)) (not (strings.Contains .Permalink "docs/")) ) -}} {{ .Permalink }}{{ if not .Lastmod.IsZero }} {{ safeHTML ( .Lastmod.Format "2006-01-02T15:04:05-07:00" ) }}{{ end }}{{ with .Sitemap.ChangeFreq }} {{ . }}{{ end }}{{ if ge .Sitemap.Priority 0.0 }} {{ .Sitemap.Priority }}{{ end }}{{ if .IsTranslated }}{{ range .Translations }} {{ end }} {{ end }} {{- end -}} {{ end }} ================================================ FILE: layouts/blog/list.html ================================================ {{ define "main" -}} {{ partial "blog/list-hero.html" . }} {{ partial "blog/posts.html" . }} {{ end -}} ================================================ FILE: layouts/blog/single.html ================================================ {{ define "main" -}} {{ partial "blog/post-hero.html" . }} {{ partial "blog/article.html" . }} {{ end -}} ================================================ FILE: layouts/docs/list.html ================================================ {{ define "main" -}} {{ partial "article.html" . }} {{ end -}} ================================================ FILE: layouts/docs/single.html ================================================ {{ define "main" -}} {{ partial "article.html" . }} {{ end -}} ================================================ FILE: layouts/http-add-on/list.html ================================================ {{ define "main" -}} {{ partial "article.html" . }} {{ end -}} ================================================ FILE: layouts/http-add-on/single.html ================================================ {{ define "main" -}} {{ partial "article.html" . }} {{ end -}} ================================================ FILE: layouts/index.html ================================================ {{ define "title" -}} {{ site.Title }} | {{ site.Params.tagline -}} {{ end }} {{ define "main" -}} {{ partial "home/hero.html" . }} {{ partial "home/what-is.html" . }} {{ partial "home/features.html" . }} {{ partial "home/video.html" . }} {{ partial "home/scalers.html" . }} {{ partial "home/samples.html" . }} {{ partial "logo-section.html" (dict "title" "Users" "description" "A variety of users are autoscaling applications with KEDA:" "logos" site.Params.users) }}
{{ partial "logo-section.html" (dict "title" "Partners" "description" "KEDA is supported by and built by our community, including the following companies:" "logos" site.Params.partners) }}
{{ partial "logo-section.html" (dict "title" "Supported by" "description" "KEDA is supported by the following companies that provide their services for free:" "logos" site.Params.supportedby) }} {{ partial "home/get-involved.html" . }} {{ partial "home/cncf.html" . }} {{ end -}} ================================================ FILE: layouts/index.redirects ================================================ {{ $docsLatest := index site.Params.versions.docs 0 -}} {{ $httpAddonLatest := index (index site.Params.versions "http-add-on") 0 -}} /docs /docs/{{ $docsLatest }} 302 /docs/latest/* /docs/{{ $docsLatest }}/:splat 302 {{ $topLevel := slice "scalers" "faq" "troubleshooting" "operate" "concepts" "deploy" -}} {{ range $name := $topLevel -}} {{ $docp := printf "docs/%s/*" $name -}} {{ $name | printf "/%-29s" }} /docs/{{ $docsLatest }}/{{ $name }} 301! {{ $docp | printf "/%-29s" }} /docs/{{ $docsLatest }}/{{ $name }}/:splat {{ end -}} /http-add-on /http-add-on/{{ $httpAddonLatest }} 302 /http-add-on/latest/* /http-add-on/{{ $httpAddonLatest }}/:splat 302 {{ $scalers := where site.RegularPages "Section" "scalers" -}} {{- range $scalers -}} {{- $path := index (split .RelPermalink "/") 2 }} /docs/scalers/{{ $path }} /scalers/{{ $path }} {{- end -}} ================================================ FILE: layouts/partials/article.html ================================================
{{ partial "nav.html" . }}
{{ partial "docs/hero.html" . }} {{ partial "content.html" . }}
================================================ FILE: layouts/partials/blog/article.html ================================================ {{ $posts := where site.RegularPages "Section" "blog" }}
{{ .Content | replaceRE "()" `${1} ${3}` | safeHTML }}
{{ partial "blog/pagination.html" . }}

Recent posts

{{ range $posts }} {{ .Title }}
{{ end }}
{{ partial "blog/rss-button.html" . }}
================================================ FILE: layouts/partials/blog/list-hero.html ================================================ {{ $title := .Title }} {{ $desc := .Description }}

{{ .Title }}

{{ $desc }}

{{ partial "blog/rss-button.html" . }}
================================================ FILE: layouts/partials/blog/pagination.html ================================================ ================================================ FILE: layouts/partials/blog/post-hero.html ================================================ {{ $title := .Title }} {{ $author := .Params.author }} {{ $date := dateFormat "January 2, 2006" .Date }} {{ if not $title }} {{ errorf "no title specified in the post you created in content/%s" .File.Path }} {{ end }} {{ if not $date }} {{ errorf "no date specified in the post you created in content/%s" .File.Path }} {{ end }} {{ if not $author }} {{ errorf "no author specified in the post you created in content/%s" .File.Path }} {{ end }}

{{ $title }}

{{ $author }}

{{ $date }}

================================================ FILE: layouts/partials/blog/posts.html ================================================ {{ $posts := where site.RegularPages "Section" "blog" }}
{{ range $posts }} {{ $title := .Title }} {{ $url := .RelPermalink }} {{ $author := .Params.author }} {{ $date := dateFormat "January 2, 2006" .Date }}

{{ $title }}

{{ with $author }}

{{ . }}

{{ end }}

{{ $date }}

{{ with .Summary }}

{{ . }}

{{ end }}
{{ end }}
================================================ FILE: layouts/partials/blog/rss-button.html ================================================ {{ $rss := .CurrentSection.OutputFormats.Get "rss" }}
RSS
================================================ FILE: layouts/partials/content.html ================================================ {{ $notice := .Params.notice }} {{ $isScaler := eq .CurrentSection.Title "Scalers" }} {{ $index := eq .File.LogicalName "_index.md"}}
{{ with $notice }}

Notice

{{ . }}
{{ end }} {{ .Content | replaceRE "()" `${1} ${3}` | safeHTML }} {{ if and ($isScaler) ($index) }} {{ partial "scaler-layout" . }} {{ end }}
================================================ FILE: layouts/partials/css.html ================================================ {{ $inDevMode := not hugo.IsProduction -}} {{ $includePaths := (slice "node_modules") -}} {{ $sass := "sass/style.sass" -}} {{ $cssOutput := "css/style.css" -}} {{ $devOpts := (dict "targetPath" $cssOutput "includePaths" $includePaths "enableSourceMap" true) -}} {{ $prodOpts := (dict "targetPath" $cssOutput "includePaths" $includePaths "outputStyle" "compressed") -}} {{ $cssOpts := cond $inDevMode $devOpts $prodOpts -}} {{ $css := resources.Get $sass | resources.ExecuteAsTemplate $sass . | css.Sass $cssOpts -}} {{ if $inDevMode -}} {{ else -}} {{ $prodCss := $css | fingerprint -}} {{ end -}} {{ range site.Params.fonts -}} {{ $fontFile := replace (lower .name) " " "-" -}} {{ range .sizes -}} {{ end -}} {{ end -}} ================================================ FILE: layouts/partials/doc-version-selector.html ================================================ {{ $releasedVersions := index site.Params.versions .Section }} {{ $unreleasedVersions := default slice (index site.Params.unreleased .Section) }} {{ $allVersions := $unreleasedVersions | append $releasedVersions }} {{ $latest := index $releasedVersions 0 }} {{ $version := "" }} {{ with .File }}{{ $version = index (split .Path "/") 1 }}{{ end }} {{ $isLatest := eq $latest $version }} {{ $isUnreleased := in $unreleasedVersions $version }} {{ $versionsOfDoc := slice }} {{ $here := (delimit (after 3 (split (delimit (split .RelPermalink "/") "," "") ",")) "/") }} {{ $path := "" }} {{ with .File }}{{ $path = .Path }}{{ end }} {{ $section := .Section }} {{ range $allVersions }} {{ $fileToCheck := replace $path $version . }} {{ if fileExists $fileToCheck }} {{ $versionsOfDoc = $versionsOfDoc | append . }} {{ end }} {{ end }} {{ $onlyOne := eq (len $versionsOfDoc) 1 }}
{{ if not $onlyOne }} {{ end }}
================================================ FILE: layouts/partials/docs/hero.html ================================================ {{ $title := .Title }} {{ $desc := .Description }} {{ $src := printf "https://github.com/kedacore/keda-docs/blob/main/content/%s" .File.Path }} {{ $availability := .Params.availability }} {{ $maintainer := .Params.maintainer }} {{ $isScaler := eq .CurrentSection.Title "Scalers" }} {{ $isSectionRoot := eq .File.BaseFileName "_index" }} {{ $version := index (split .File.Path "/") 1 }} {{ $latest := index (index site.Params.versions .Section) 0 }} {{ $isLatest := eq $version $latest }} {{ $isNextVersion := not (in (index site.Params.versions .Section) $version) }} {{ $productNames := dict "docs" "KEDA" "http-add-on" "HTTP Add-on" }} {{ $productName := index $productNames .Section }} {{ $latestUrl := replaceRE $version $latest .RelPermalink }} {{ $latestPageExists := false }} {{ range site.Pages }} {{ if eq .RelPermalink $latestUrl }} {{ $latestPageExists = true }} {{ end }} {{ end }}

{{ $title }} {{ if $isLatest }} Latest {{ else if and (not $isNextVersion) $latestPageExists }} Click here for latest {{ end }}

{{ with $desc }}

{{ . }}

{{ end }} {{ if or $availability $maintainer (and $isScaler (not $isSectionRoot)) }}

{{ with $availability }} Availability: {{ . }} {{ end }} {{ with $maintainer }} Maintainer: {{ . }} {{ end }} {{ if and $isScaler (not $isSectionRoot) }} {{ $url := printf "https://github.com/kedacore/keda/blob/main/pkg/scalers/%s.go" .Params.go_file }}
Scaler code
{{ end }}

{{ end }}
{{ partial "doc-version-selector.html" . }} Suggest a change
{{ if and (not $isLatest) $latestPageExists }}

Warning

You are currently viewing v{{ $version }} of the documentation and it is not the latest. For the most recent documentation, kindly click here.
{{ else if and (not $isLatest) (not $isNextVersion) }}

Notice

This page does not exist in the latest version ({{ $latest }}). It may have been deprecated or replaced. Check the {{ $latest }} documentation for alternatives.
{{ end }}
================================================ FILE: layouts/partials/favicon.html ================================================ {{ $favicon := site.Params.favicon | absURL }} {{ with $favicon }} {{ $url := . | relURL }} {{ end }} ================================================ FILE: layouts/partials/footer.html ================================================ {{ $title := site.Title }} {{ $logo := printf "img/logos/%s" site.Params.logos.footer | relURL }} {{ $year := now.Year }} {{ $menu := site.Menus.main }} {{ $btns := dict "btns" site.Params.social "color" "white" "outlined" true }}
{{ range $menu }} {{ $isExternal := hasPrefix .URL "http" }}

{{ .Name }} {{ if $isExternal }} {{ end }}

{{ end }}
{{ partial "social-buttons.html" $btns }}

© KEDA Authors 2014-{{ $year }} | Documentation Distributed under CC-BY-4.0


© {{ $year }} The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.

================================================ FILE: layouts/partials/general-version-selector.html ================================================ {{ $allVersions := site.Params.versions.docs }} {{ $latest := index $allVersions 0 }} {{ $version := "" }} {{ with .File }}{{ $version = index (split .Path "/") 1 }}{{ end }} {{ $isLatest := eq $latest $version }} {{ $onlyOne := eq (len $allVersions) 1 }}
{{ if not $onlyOne }} {{ end }}
================================================ FILE: layouts/partials/headline-hash.html ================================================ {{ . | replaceRE "()" `${1} ${3}` | safeHTML }} ================================================ FILE: layouts/partials/hero.html ================================================ {{ $title := .Title }} {{ $desc := .Description }}

{{ .Title }}

{{ with $desc }}

{{ . }}

{{ end }}
================================================ FILE: layouts/partials/home/cncf.html ================================================ {{ $logo := "img/logos/cncf-color.png" | relURL }}

KEDA is a Cloud Native Computing Foundation graduated project

================================================ FILE: layouts/partials/home/features.html ================================================ {{ $features := site.Params.features }}

Features


{{ range $features }}

{{ .title }}

{{ .content | markdownify }}

{{ end }}
================================================ FILE: layouts/partials/home/get-involved.html ================================================ {{ with site.GetPage "/community" }}

Get Involved

{{ partial "include.html" "get-involved.md" }}
{{ end }} ================================================ FILE: layouts/partials/home/hero.html ================================================ {{ $logo := printf "img/logos/%s" site.Params.logos.hero | relURL }} {{ $desc := site.Params.description | markdownify }} {{ $btns := site.Menus.buttons }} {{ $sect := .Section }} {{ $docsL := index site.Params.versions.docs 0 }}

Kubernetes Event-driven Autoscaling

{{ $desc }}


{{ range $btns }} {{ $url := "" }} {{ if (hasPrefix .URL "/docs") }} {{ $url = replaceRE "/docs" (printf "/docs/%s" $docsL) .URL }} {{ else if (hasPrefix .URL "/http-add-on/") }} {{ $url = replace .URL "/http-add-on/" "/http-add-on/latest/" }} {{ else }} {{ $url = .URL }} {{ end }} {{ with .Pre }} {{ end }} {{ .Name }} {{ end }}
================================================ FILE: layouts/partials/home/samples.html ================================================ {{ $samples := site.Params.samples }}

Highlighted Samples

We provide a variety of samples, but here are some of our highlights:

{{ range $samples }}

{{ .title }}

{{ .content | markdownify }}

{{ end }}
================================================ FILE: layouts/partials/home/scalers.html ================================================ {{ $latest := index site.Params.versions.docs 0 }} {{ $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" }}

Scalers

Scalers represent event sources that KEDA can scale based on


{{ range $scalers }} {{ $version := index (split .File.Path "/") 1 }} {{ if eq $version $latest }} {{ .Render "card-info" }} {{ end }} {{ end }}
================================================ FILE: layouts/partials/home/video.html ================================================
{{ partial "youtube-embed.html" (dict "youtube_id" "317rLOIKfDQ") }}

KEDA: Unlocking Advanced Event-Driven Scaling for Kubernetes

From KubeCon Europe 2025

Scaling New Heights with KEDA: Performance, Extensions, and Beyond

From KubeCon Europe 2024

{{ partial "youtube-embed.html" (dict "youtube_id" "_5_njiPr5vg") }}
{{ partial "youtube-embed.html" (dict "youtube_id" "wYQ2cvSj6os") }}

Exploring KEDA's Graduation and Advancements in Event-Driven Scaling

From KubeCon North America 2023

================================================ FILE: layouts/partials/home/what-is.html ================================================ {{ $whatIs := site.Params.what_is | markdownify }}

What is KEDA?

{{ $whatIs }}
================================================ FILE: layouts/partials/include.html ================================================ {{ $path := printf "includes/%s" . }} {{ readFile $path | markdownify }} ================================================ FILE: layouts/partials/javascript.html ================================================ {{ $inDevMode := not hugo.IsProduction }} {{/* Alpine.js */}} {{ $alpine := resources.Get "js/alpine.js" | js.Build (dict "targetPath" "js/alpine.js") }} {{ if $inDevMode }} {{ else }} {{ $alpine = $alpine | minify | fingerprint }} {{ end }} {{/* DocSearch */}} {{ $latestDocs := index site.Params.versions.docs 0 }} {{ $latestHttpAddon := "" }} {{ with index site.Params.versions "http-add-on" }}{{ $latestHttpAddon = index . 0 }}{{ end }} {{ $dsParams := dict "latestDocs" $latestDocs "latestHttpAddon" $latestHttpAddon "apiKey" site.Params.docsearch.apiKey "appId" site.Params.docsearch.appId "indexName" site.Params.docsearch.indexName }} {{ $docsearchOpts := dict "targetPath" "js/docsearch.js" "params" $dsParams }} {{ $docsearch := resources.Get "js/docsearch.js" | js.Build $docsearchOpts }} {{ if $inDevMode }} {{ else }} {{ $docsearch = $docsearch | minify | fingerprint }} {{ end }} {{/* Scaler search and filter (bundles Lunr.js) */}} {{ $scalerSearch := resources.Get "js/scaler-search.js" | js.Build (dict "targetPath" "js/scaler-search.js") }} {{ if $inDevMode }} {{ else }} {{ $scalerSearch = $scalerSearch | minify | fingerprint }} {{ end }} {{/* Site utilities (anchor offset, clipboard, FAQ accordion) */}} {{ $site := resources.Get "js/site.js" | js.Build (dict "targetPath" "js/site.js") }} {{ if $inDevMode }} {{ else }} {{ $site = $site | minify | fingerprint }} {{ end }} ================================================ FILE: layouts/partials/logo-section.html ================================================

{{ .title }}

{{ .description }}


{{ range .logos }} {{ $logo := printf "img/logos/%s" .logo | relURL }}
Logo
{{ end }}
================================================ FILE: layouts/partials/meta.html ================================================ {{ $url := .Permalink }} {{ $latestVersion := index site.Params.versions.docs 0 -}} {{ $canonical := replaceRE "/docs/\\d.\\d+" (printf "/docs/%s" $latestVersion) $url }} {{ $title := cond .IsHome site.Title (printf "%s | %s" site.Title .Title) }} {{ $type := cond .IsHome "website" "article" }} {{ $desc := cond .IsHome site.Params.description .Description }} {{ $twitter := site.Params.twitter_handle }} {{ $img := "img/logos/keda-icon-color.png" | absURL }} {{ $imgAlt := printf "%s color logo" site.Title }} {{ $locale := site.Params.locale }} {{ $sectionVersions := index site.Params.versions .Section }} {{ $version := "" }} {{ if $sectionVersions }} {{ with .File }}{{ $version = index (split .Path "/") 1 }}{{ end }} {{ end }} {{ with .OutputFormats.Get "rss" -}} {{ printf `` .Rel .MediaType.Type $url site.Title | safeHTML }} {{ end -}} {{/* When $version is a released version that is not the latest, add a "noindex" meta tag to exclude it from search engines. Unreleased and latest versions remain indexable. */}} {{ if ne $version "" }} {{ $isOldVersion := and (in $sectionVersions $version) (ne $version (index $sectionVersions 0)) }} {{ if $isOldVersion }} {{ end }} {{ end }} {{/* Twitter Card metadata */}} {{ $tag := .Section }} {{ if ne $version "" }}{{ $tag = printf "%s-%s" .Section $version }}{{ end }} {{/* OpenGraph metadata */}} {{ with $desc }} {{ end }} {{ if hugo.IsProduction -}} {{ template "_internal/google_analytics.html" . -}} {{ end -}} ================================================ FILE: layouts/partials/nav.html ================================================ {{ $here := .RelPermalink }} {{ $docs := where site.Sections "Section" .Section }} {{ $currentSection := .CurrentSection }} {{ $root := .FirstSection }} {{ $thisVersion := index (split .File.Path "/") 1 }}
{{ range $docs }} {{ range .Sections }} {{ $version := index (split .File.Path "/") 1 }} {{ $sameVersion := eq $version $thisVersion }} {{ if $sameVersion }} {{ $isThisSection := eq .CurrentSection.Title $currentSection.Title }} {{ $isHere := eq $here .RelPermalink }}
{{ .Title }} {{ if .RegularPages }} {{ end }}
{{ with .RegularPages }}
    {{ range . }} {{ $isHere := eq $here .RelPermalink }} {{ $title := cond (isset .Params "short") .Params.short .Title }}
  • {{ $title }}
    • {{ if $isHere }} {{ if gt (len .TableOfContents) 32 }}
    {{ .TableOfContents }}
    {{ end }} {{ end }} {{ end }}
{{ end }}
{{ with .Sections }} {{ range . }} {{ $isThisSection := eq .CurrentSection.Title $currentSection.Title }} {{ $regularPages := .RegularPages -}}
{{ .Title }} {{ if $regularPages }} {{ end }}
{{ with $regularPages }}
    {{ range . }} {{ $isHere := eq $here .RelPermalink }} {{ $title := cond (isset .Params "short") .Params.short .Title }}
  • {{ $title }}
    • {{ if $isHere }} {{ if gt (len .TableOfContents) 32 }}
    {{ .TableOfContents }}
    {{ end }} {{ end }} {{ end }}
{{ end }}
{{ end }} {{ end }} {{ end }} {{ end }} {{ end }}
================================================ FILE: layouts/partials/navbar.html ================================================ {{ $home := site.BaseURL }} {{ $here := .RelPermalink }} {{ $logo := site.Params.logos.navbar }} {{ $menu := site.Menus.main }} {{ $docs := site.Menus.docs }} {{ $social := site.Params.social }} {{ $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" }} ================================================ FILE: layouts/partials/scaler-layout.html ================================================

Currently available scalers for KEDA

FILTER
Type
Category
{{ $categories := slice }} {{ range $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" }} {{ with $scalers.Params.category }} {{ $categories = $categories | append ($scalers.Params.category) }} {{ $categories = uniq $categories }} {{ end }} {{ end }} {{ range $categories }} {{ $category := . }}
{{ end }}
Maintainer
{{ $maintainers := slice }} {{ range $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" }} {{ $maintainers = $maintainers | append ($scalers.Params.maintainer) }} {{ $maintainers = uniq $maintainers }} {{ end }} {{ range $maintainers }} {{ $maintainer := . }}
{{ end }}
{{ partial "scaler-template" . }}
================================================ FILE: layouts/partials/scaler-template.html ================================================ ================================================ FILE: layouts/partials/scalers.html ================================================ {{ $here := $.Page.RelPermalink }} {{ $scalers := where site.RegularPages ".CurrentSection.Title" "Scalers" }} {{ $version := index (split $.Page.File.Path "/") 1 }}
{{ range $scalers }} {{ $isHere := eq .RelPermalink $here }} {{ $thisVersion := index (split .File.Path "/") 1 }} {{ $sameVersion := eq $version $thisVersion }} {{ if $sameVersion }} {{ .Title }} {{ end }} {{ end }}
================================================ FILE: layouts/partials/social-buttons.html ================================================ {{ $compact := .compact }} {{ $outlined := .outlined }} {{ range .btns }} {{ if not $compact }} {{ .name }} {{ end }} {{ end }} ================================================ FILE: layouts/partials/youtube-embed.html ================================================ {{ $src := printf "https://www.youtube.com/embed/%s" .youtube_id }} ================================================ FILE: layouts/scalers/list.html ================================================ {{ define "title" }} KEDA Scalers {{ end }} {{ define "main" }}
{{ partial "nav.html" . }}
{{ partial "docs/hero.html" . }} {{ partial "content.html" . }}
{{ end }} ================================================ FILE: layouts/shortcodes/authentication-providers.html ================================================ {{ $here := $.Page.RelPermalink }} {{ $providers := where site.RegularPages ".CurrentSection.Title" "Authentication Providers" }} {{ $version := index (split $.Page.File.Path "/") 1 }}
{{ range $providers }} {{ $thisVersion := index (split .File.Path "/") 1 }} {{ $sameVersion := eq $version $thisVersion }} {{ if $sameVersion }} {{ .Title }} {{ end }} {{ end }}
================================================ FILE: layouts/shortcodes/collapsible.html ================================================

{{ .Get 0 }}

{{ .Inner | markdownify }}
================================================ FILE: layouts/shortcodes/enterprise.html ================================================ {{ $vendors := site.Params.vendors }}
{{ range $vendors }}
{{ .name }}
{{ .description | markdownify }}
{{ range .urls }} {{ .text }} {{ end }}
{{ end }}

Requirements for Listing a Vendor

To be listed as a KEDA commercial offering, organizations must meet the following criteria:

  • Demonstrate a commitment to KEDA's maintenance and improvement.
    • On average, have pull requests accepted monthly into KEDA or related projects for features and/or improvements.
    • Have made a substantial contribution to the development of KEDA or related projects.
    • Help triage and comment on issues across the KEDA ecosystem at least 3 times per month.
  • Demonstrate an area of expertise in the KEDA ecosystem.
    • Example: Employing one or more KEDA maintainers.
    • Example: Owning a specific high-impact feature or process.
  • Participate in KEDA's governance.
    • At least 1 member of the vendor's team attends the community meetings at least 50% of the time.
  • Be active KEDA thought leaders.
    • Example: Sponsoring staff for KEDA booths or community events.
    • Example: Giving talks related to KEDA or its ecosystem.
  • Provide enterprise-level support and functionality for KEDA or products based directly on it.

If any questions arise regarding eligibility, the KEDA maintainers will make the final decision.

================================================ FILE: layouts/shortcodes/faq.html ================================================ {{ $faq := hugo.Data.faq.qna }} {{ range $faq }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }} ================================================ FILE: layouts/shortcodes/faq20.html ================================================ {{ $filename := .Get "versionData" }} {{ range index hugo.Data $filename }} {{ $.Scratch.Add "faq20" . }} {{ end }} {{ $faq20 := $.Scratch.Get "faq20" }}

General

{{ range where $faq20 ".type" "==" "General" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }}

Best Practices

{{ range where $faq20 ".type" "==" "Best Practices" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }}

Features

{{ range where $faq20 ".type" "==" "Features" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }}

Kubernetes

{{ range where $faq20 ".type" "==" "Kubernetes" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }}

Community

{{ range where $faq20 ".type" "==" "Community" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }}

Website

{{ range where $faq20 ".type" "==" "Website" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }}

Integrations

Microsoft Azure

{{ range where $faq20 ".type" "==" "Azure" }} {{ $question := .q | markdownify }} {{ $answer := .a | markdownify }} {{ $id := .q | urlize }}

{{ $question }}

{{ $answer }}
{{ end }} ================================================ FILE: layouts/shortcodes/include.html ================================================ {{ partial "include.html" (.Get 0) }} ================================================ FILE: layouts/shortcodes/integrations.html ================================================ {{ $latest := index site.Params.versions.docs 0 }} {{ $integrations := where site.RegularPages ".CurrentSection.Title" "Integrations" }}
{{ range $integrations }} {{ $version := index (split .File.Path "/") 1 }} {{ if eq $version $latest }} {{ .Render "card-info" }} {{ end }} {{ end }}
================================================ FILE: layouts/shortcodes/partners-icons.html ================================================ {{ $companies := site.Params.partners }}
{{ range $companies }} {{ $logo := printf "img/logos/%s" .logo | relURL }}
{{ end }}
================================================ FILE: layouts/shortcodes/scalers-compact.html ================================================ {{ partial "scalers.html" . }} ================================================ FILE: layouts/shortcodes/supportedby-icons.html ================================================ {{ $companies := site.Params.supportedby }}
{{ range $companies }} {{ $logo := printf "img/logos/%s" .logo | relURL }}
{{ end }}
================================================ FILE: layouts/shortcodes/troubleshooting.html ================================================ {{ $issues := where site.RegularPages "Section" "troubleshooting" }} {{ range $issues }} {{ $problem := .Title | markdownify }} {{ $solution := .Content }} {{ $id := .Title | urlize }}

{{ $problem }}

{{ $solution }}
{{ end }} ================================================ FILE: layouts/shortcodes/user-icons.html ================================================ {{ $users := site.Params.users }}
{{ range $users }} {{ $logo := printf "img/logos/%s" .logo | relURL }}
{{ end }}
================================================ FILE: netlify.toml ================================================ [build] publish = "public" command = "npm run build:preview" [context.production] command = "npm run build:production" ================================================ FILE: package.json ================================================ { "name": "keda-docs", "private": true, "scripts": { "build": "hugo --cleanDestinationDir -e dev -DFE", "build:preview": "hugo --cleanDestinationDir --minify -e dev -DFE --baseURL \"${DEPLOY_PRIME_URL:-/}\"", "build:production": "hugo --cleanDestinationDir --minify", "check:links": "HTMLTEST_ARGS='--log-level 1 --skip-external' make --keep-going check-links", "precheck:links": "npm run build", "serve": "netlify dev -c \"hugo serve -DFE\" --framework hugo", "serve:hugo": "hugo serve -DFE" }, "devDependencies": { "@docsearch/css": "4.6.2", "@docsearch/js": "4.6.2", "@fontsource/inria-sans": "5.2.8", "@fontsource/roboto-mono": "5.2.8", "@fortawesome/fontawesome-free": "7.2.0", "alpinejs": "3.15.11", "bulma": "0.8.2", "hugo-extended": "0.160.1", "lunr": "2.3.9", "netlify-cli": "25.2.0" } } ================================================ FILE: static/_redirects ================================================ /concepts/* /docs/concepts/:splat /concepts/overview /docs/concepts /deploy/* /docs/deploy/:splat /faq/* /docs/faq/ ================================================ FILE: static/img/keda-arch-new-source.excalidraw ================================================ { "type": "excalidraw", "version": 2, "source": "https://excalidraw.com", "elements": [ { "id": "bg", "type": "rectangle", "x": -149.89991188942338, "y": 177.6216165027413, "width": 883.3515625000001, "height": 691.20703125, "strokeColor": "#1971c2", "backgroundColor": "#e7f5ff", "fillStyle": "hachure", "strokeWidth": 2, "roughness": 1, "opacity": 30, "angle": 0, "seed": 1837477438, "version": 773, "versionNonce": 2059255378, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "qs6l3Ff7lzQJs220D4VYv", "type": "arrow" } ], "updated": 1774108999850, "roundness": { "type": 3 }, "index": "a0", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "bg-label", "type": "text", "x": -100.05078125, "y": 162.28515625, "width": 183.5600128173828, "height": 25, "text": "Kubernetes Cluster", "fontSize": 20, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#1971c2", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 9001, "version": 192, "versionNonce": 1132167330, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473875, "index": "a1", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Kubernetes Cluster", "autoResize": true, "lineHeight": 1.25 }, { "id": "eventsource-box", "type": "rectangle", "x": 200, "y": 99.87109375, "width": 360, "height": 64, "strokeColor": "#495057", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1054254208, "version": 9, "versionNonce": 724676990, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "roundness": { "type": 3 }, "strokeStyle": "dashed", "index": "a2", "frameId": null, "link": null, "locked": false }, { "id": "eventsource-label", "type": "text", "x": 319.8125, "y": 111.14453125, "width": 126.25200653076172, "height": 22.5, "text": "Event Sources", "fontSize": 18, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#343a40", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 102, "version": 97, "versionNonce": 1256423614, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332702446, "index": "a3", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Event Sources", "autoResize": true, "lineHeight": 1.25 }, { "id": "eventsource-sub", "type": "text", "x": 253.4296875, "y": 143.296875, "width": 249.8760223388672, "height": 15, "text": "Kafka · RabbitMQ · Elasticsearch · SQS · ...", "fontSize": 12, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#868e96", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 103, "version": 116, "versionNonce": 1935761662, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "arrow-1", "type": "arrow" } ], "updated": 1773332708497, "index": "a4", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Kafka · RabbitMQ · Elasticsearch · SQS · ...", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-1-label", "type": "text", "x": 395.98828125, "y": 178.23828125, "width": 72.72200012207031, "height": 16.25, "text": "Poll metrics", "fontSize": 13, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#f08c00", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 202, "version": 43, "versionNonce": 1636887522, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "a6", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Poll metrics", "autoResize": true, "lineHeight": 1.25 }, { "id": "keda-bg", "type": "rectangle", "x": 99.66024179131637, "y": 219.27977561057673, "width": 575.3671875, "height": 168.23437500000009, "strokeColor": "#1971c2", "backgroundColor": "#dbe4ff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 60, "angle": 0, "seed": 1703810176, "version": 197, "versionNonce": 770048638, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "Dg1JH1y9woiD2txdgGma3", "type": "arrow" } ], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "a7", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "keda-bg-label", "type": "text", "x": 352.74609375, "y": 226.15234375, "width": 49.06800079345703, "height": 22.5, "text": "KEDA", "fontSize": 18, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#1864ab", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 301, "version": 131, "versionNonce": 1845317646, "isDeleted": true, "groupIds": [], "boundElements": [ { "id": "arrow-1", "type": "arrow" } ], "updated": 1774109188209, "index": "a8", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "KEDA", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-1", "type": "arrow", "x": 377.38294606562573, "y": 220.15234375000003, "width": 0.9117950872238794, "height": 55.85546875000003, "points": [ [ 0, 0 ], [ 0.9117950872238794, -55.85546875000003 ] ], "strokeColor": "#f08c00", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 832471936, "version": 389, "versionNonce": 2001338322, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1774109188209, "startArrowhead": null, "endArrowhead": "arrow", "index": "a8V", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": null, "endBinding": { "elementId": "eventsource-sub", "mode": "orbit", "fixedPoint": [ 0.5001, 1 ] }, "moveMidPointsWithElement": false }, { "id": "operator-box", "type": "rectangle", "x": 120, "y": 251.87109375, "width": 160, "height": 72, "strokeColor": "#1971c2", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 601326720, "version": 6, "versionNonce": 831913618, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1774108954716, "roundness": { "type": 3 }, "index": "a9", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "operator-label", "type": "text", "x": 129.98828125, "y": 264.23828125, "width": 95.88600158691406, "height": 17.5, "text": "keda-operator", "fontSize": 14, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#1864ab", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 311, "version": 32, "versionNonce": 340581218, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aA", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "keda-operator", "autoResize": true, "lineHeight": 1.25 }, { "id": "operator-sub", "type": "text", "x": 131.41734313964844, "y": 286.36328125, "width": 137.52200317382812, "height": 27.5, "text": "Watches KEDA Resources\nManages HPA lifecycle", "fontSize": 11, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#495057", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 312, "version": 112, "versionNonce": 1719912910, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "QqNXFuLZrly8QpmmjaPyO", "type": "arrow" }, { "id": "qs6l3Ff7lzQJs220D4VYv", "type": "arrow" } ], "updated": 1774108954716, "index": "aB", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Watches KEDA Resources\nManages HPA lifecycle", "autoResize": true, "lineHeight": 1.25 }, { "id": "metrics-box", "type": "rectangle", "x": 300, "y": 251.87109375, "width": 160, "height": 72, "strokeColor": "#1971c2", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 930280576, "version": 4, "versionNonce": 399346686, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "aC", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "metrics-label", "type": "text", "x": 307.98828125, "y": 264.23828125, "width": 141.3360137939453, "height": 16.25, "text": "keda-metrics-apiserver", "fontSize": 13, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#1864ab", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 321, "version": 32, "versionNonce": 628288226, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aD", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "keda-metrics-apiserver", "autoResize": true, "lineHeight": 1.25 }, { "id": "metrics-sub", "type": "text", "x": 311.7717819213867, "y": 286.2265625, "width": 135.2010040283203, "height": 27.5, "text": "Exposes external metrics\nto Kubernetes HPA", "fontSize": 11, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#495057", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 322, "version": 53, "versionNonce": 660029090, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "o5AIWHv-1YltESqUftZiA", "type": "arrow" } ], "updated": 1773332473876, "index": "aE", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Exposes external metrics\nto Kubernetes HPA", "autoResize": true, "lineHeight": 1.25 }, { "id": "webhooks-box", "type": "rectangle", "x": 480, "y": 251.87109375, "width": 160, "height": 72, "strokeColor": "#1971c2", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 639657088, "version": 4, "versionNonce": 1142940862, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "aF", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "webhooks-label", "type": "text", "x": 488.11328125, "y": 264.11328125, "width": 146.9399871826172, "height": 15, "text": "keda-admission-webhooks", "fontSize": 12, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#1864ab", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 331, "version": 30, "versionNonce": 1492851298, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aG", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "keda-admission-webhooks", "autoResize": true, "lineHeight": 1.25 }, { "id": "webhooks-sub", "type": "text", "x": 491.0558433532715, "y": 287.37109375, "width": 141.7570037841797, "height": 27.5, "text": "Validates KEDA Resources\nconfiguration on apply", "fontSize": 11, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#495057", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 332, "version": 127, "versionNonce": 1012882446, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1774109005031, "index": "aH", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Validates KEDA Resources\nconfiguration on apply", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-2-label", "type": "text", "x": 208.01034545898438, "y": 335.05078125, "width": 103.23300170898438, "height": 32.5, "text": "Create / update\nHPA resource", "fontSize": 13, "fontFamily": 5, "textAlign": "right", "verticalAlign": "top", "strokeColor": "#f08c00", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 402, "version": 146, "versionNonce": 1423796706, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aJ", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Create / update\nHPA resource", "autoResize": true, "lineHeight": 1.25 }, { "id": "apiserver-box", "type": "rectangle", "x": 240, "y": 395.87109375, "width": 280, "height": 64, "strokeColor": "#495057", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 366376064, "version": 9, "versionNonce": 1166054846, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "o5AIWHv-1YltESqUftZiA", "type": "arrow" }, { "id": "arrow-3a", "type": "arrow" } ], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "aK", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "apiserver-label", "type": "text", "x": 280.11328125, "y": 415.98828125, "width": 188.61500549316406, "height": 21.25, "text": "Kubernetes API Server", "fontSize": 17, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#343a40", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 501, "version": 32, "versionNonce": 588897698, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aL", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Kubernetes API Server", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-3a", "type": "arrow", "x": 380.028, "y": 505.99609375, "width": 0, "height": 40.125, "points": [ [ 0, 0 ], [ 0, -40.125 ] ], "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 302125952, "version": 106, "versionNonce": 810073662, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "startArrowhead": null, "endArrowhead": "arrow", "index": "aM", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": { "elementId": "hpa-box", "mode": "orbit", "fixedPoint": [ 0.5001, 0 ] }, "endBinding": { "elementId": "apiserver-box", "mode": "orbit", "fixedPoint": [ 0.5001, 1 ] }, "moveMidPointsWithElement": false }, { "id": "arrow-3a-label", "type": "text", "x": 394.11328125, "y": 474.11982046790916, "width": 143.364013671875, "height": 16.25, "text": "Query external metrics", "fontSize": 13, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 602, "version": 41, "versionNonce": 554817890, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aN", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Query external metrics", "autoResize": true, "lineHeight": 1.25 }, { "id": "hpa-box", "x": 240, "y": 511.99609375, "type": "rectangle", "width": 280, "height": 64, "strokeColor": "#495057", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1813243008, "version": 21, "versionNonce": 209766078, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "arrow-3a", "type": "arrow" }, { "id": "qs6l3Ff7lzQJs220D4VYv", "type": "arrow" }, { "id": "QqNXFuLZrly8QpmmjaPyO", "type": "arrow" } ], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "aO", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "hpa-label", "type": "text", "x": 276.74527740478516, "y": 529.98828125, "width": 203.96800231933594, "height": 20, "text": "Horizontal Pod Autoscaler", "fontSize": 16, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#343a40", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 701, "version": 30, "versionNonce": 1578392866, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aP", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Horizontal Pod Autoscaler", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-4", "type": "arrow", "x": 380, "y": 575.87109375, "width": 0, "height": 52, "points": [ [ 0, 0 ], [ 0, 52 ] ], "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1064543104, "version": 5, "versionNonce": 1739632446, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "startArrowhead": null, "endArrowhead": "arrow", "index": "aQ", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": null, "endBinding": null }, { "id": "arrow-4-label", "type": "text", "x": 424.74609375, "y": 595.76171875, "width": 223.62599182128906, "height": 16.25, "text": "Scale up / down (1 → N and N → 1)", "fontSize": 13, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 802, "version": 129, "versionNonce": 663775458, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aR", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Scale up / down (1 → N and N → 1)", "autoResize": true, "lineHeight": 1.25 }, { "id": "deployment-bg", "type": "rectangle", "x": 200, "y": 627.87109375, "width": 360, "height": 120, "strokeColor": "#495057", "backgroundColor": "#f8f9fa", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 2032358528, "version": 16, "versionNonce": 198246930, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "qs6l3Ff7lzQJs220D4VYv", "type": "arrow" } ], "updated": 1774108954716, "roundness": { "type": 3 }, "index": "aS", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "deployment-label", "type": "text", "x": 335.87890625, "y": 639.00390625, "width": 87.80799865722656, "height": 20, "text": "Deployment", "fontSize": 16, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#343a40", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 901, "version": 60, "versionNonce": 2096376766, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332498707, "index": "aT", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Deployment", "autoResize": true, "lineHeight": 1.25 }, { "id": "replicaset-box", "type": "rectangle", "x": 260, "y": 665.87109375, "width": 240, "height": 68, "strokeColor": "#2f9e44", "backgroundColor": "#ebfbee", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 453768064, "version": 5, "versionNonce": 119021630, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "HjCxtbTJ1WaKIcEEZiiYh", "type": "arrow" } ], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "aU", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "replicaset-label", "type": "text", "x": 346.328125, "y": 692.2734375, "width": 76.06500244140625, "height": 18.75, "text": "ReplicaSet", "fontSize": 15, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 911, "version": 94, "versionNonce": 1825111970, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332491611, "index": "aV", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "ReplicaSet", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-5", "type": "arrow", "x": 380, "y": 747.87109375, "width": 164.08227272727248, "height": 38, "points": [ [ 0, 0 ], [ -164.08227272727248, 38 ] ], "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 108659584, "version": 235, "versionNonce": 1337814754, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332652477, "startArrowhead": null, "endArrowhead": "arrow", "index": "aW", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": null, "endBinding": { "elementId": "pod1-box", "mode": "orbit", "fixedPoint": [ 0.5001, 0 ] }, "moveMidPointsWithElement": false }, { "id": "arrow-5-label", "type": "text", "x": 269, "y": 772.87109375, "width": 98.74800109863281, "height": 16.25, "text": "Desired replicas", "fontSize": 13, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1002, "version": 231, "versionNonce": 1695792162, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aX", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Desired replicas", "autoResize": true, "lineHeight": 1.25 }, { "id": "pod1-box", "type": "rectangle", "x": 140, "y": 791.87109375, "width": 100, "height": 48, "strokeColor": "#2f9e44", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 314885248, "version": 7, "versionNonce": 766591650, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "arrow-5", "type": "arrow" } ], "updated": 1773332652478, "roundness": { "type": 3 }, "index": "aY", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "pod1-label", "type": "text", "x": 165, "y": 807.87109375, "width": 37.79999923706055, "height": 17.5, "text": "Pod 1", "fontSize": 14, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1102, "version": 27, "versionNonce": 1967908834, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "aZ", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Pod 1", "autoResize": true, "lineHeight": 1.25 }, { "id": "pod2-box", "type": "rectangle", "x": 330, "y": 791.87109375, "width": 100, "height": 48, "strokeColor": "#2f9e44", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1454912640, "version": 4, "versionNonce": 1841191358, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "aa", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "pod2-label", "type": "text", "x": 355, "y": 807.87109375, "width": 41.62200164794922, "height": 17.5, "text": "Pod 2", "fontSize": 14, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1104, "version": 27, "versionNonce": 1829280674, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "ab", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Pod 2", "autoResize": true, "lineHeight": 1.25 }, { "id": "podellipsis", "type": "text", "x": 446, "y": 807.87109375, "width": 12, "height": 25, "text": "···", "fontSize": 20, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1105, "version": 27, "versionNonce": 2054739810, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "ac", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "···", "autoResize": true, "lineHeight": 1.25 }, { "id": "podn-box", "type": "rectangle", "x": 520, "y": 791.87109375, "width": 100, "height": 48, "strokeColor": "#2f9e44", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 717071488, "version": 7, "versionNonce": 1572244094, "isDeleted": false, "groupIds": [], "boundElements": [ { "id": "HjCxtbTJ1WaKIcEEZiiYh", "type": "arrow" } ], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "ad", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "podn-label", "type": "text", "x": 545, "y": 807.87109375, "width": 40.66999816894531, "height": 17.5, "text": "Pod N", "fontSize": 14, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1107, "version": 27, "versionNonce": 770415394, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "ae", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Pod N", "autoResize": true, "lineHeight": 1.25 }, { "id": "scaledobject-box", "type": "rectangle", "x": -139.2899307594651, "y": 214.75261089568198, "width": 209.99481430062707, "height": 241.9639885457811, "strokeColor": "#862e9c", "backgroundColor": "#f8f0fc", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 397444224, "version": 622, "versionNonce": 1747681102, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1774108921491, "roundness": { "type": 3 }, "index": "af", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "scaledobject-label", "type": "text", "x": -120.04029846191406, "y": 235.83593750000006, "width": 177.59922790527344, "height": 12.382812499999991, "text": "Custom Resource Definitions (CRDs)", "fontSize": 9.906249999999993, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#862e9c", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1201, "version": 460, "versionNonce": 902817506, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473876, "index": "ag", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Custom Resource Definitions (CRDs)", "autoResize": true, "lineHeight": 1.25 }, { "id": "crd1-box", "type": "rectangle", "x": -116.55859375, "y": 272.84375, "width": 160.16172963877017, "height": 54.405311089650816, "strokeColor": "#862e9c", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 1.5, "roughness": 0, "opacity": 100, "angle": 0, "seed": 934896768, "version": 287, "versionNonce": 2125880190, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "ah", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "crd1-label", "type": "text", "x": -106.5703125, "y": 283.328125, "width": 81.54900360107422, "height": 16.25, "text": "ScaledObject", "fontSize": 13, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#862e9c", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1211, "version": 176, "versionNonce": 448051874, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "ai", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "ScaledObject", "autoResize": true, "lineHeight": 1.25 }, { "id": "crd1-sub", "type": "text", "x": -106.69140625, "y": 301.6953125, "width": 126.72000885009766, "height": 12.5, "text": "Deployment / StatefulSet", "fontSize": 10, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#868e96", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1212, "version": 237, "versionNonce": 2068387426, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "aj", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Deployment / StatefulSet", "autoResize": true, "lineHeight": 1.25 }, { "id": "crd2-box", "type": "rectangle", "x": -117.47187536703723, "y": 332.6039267683359, "width": 160, "height": 52, "strokeColor": "#862e9c", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 1.5, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1393181824, "version": 411, "versionNonce": 162587710, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419183, "roundness": { "type": 3 }, "index": "ak", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "crd2-label", "type": "text", "x": -107.60468786703723, "y": 343.4164267683359, "width": 62.30899429321289, "height": 16.25, "text": "ScaledJob", "fontSize": 13, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#862e9c", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1221, "version": 502, "versionNonce": 1213987362, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "al", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "ScaledJob", "autoResize": true, "lineHeight": 1.25 }, { "id": "crd2-sub", "type": "text", "x": -107.48359411703723, "y": 361.0492392683359, "width": 112.33000946044922, "height": 12.5, "text": "Batch / Job workloads", "fontSize": 10, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#868e96", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1222, "version": 440, "versionNonce": 14444002, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "am", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Batch / Job workloads", "autoResize": true, "lineHeight": 1.25 }, { "id": "crd3-box", "type": "rectangle", "x": -116.71796911703723, "y": 395.5375205183359, "width": 160, "height": 52, "strokeColor": "#862e9c", "backgroundColor": "#ffffff", "fillStyle": "solid", "strokeWidth": 1.5, "roughness": 0, "opacity": 100, "angle": 0, "seed": 933438592, "version": 242, "versionNonce": 1086792958, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419184, "roundness": { "type": 3 }, "index": "an", "strokeStyle": "solid", "frameId": null, "link": null, "locked": false }, { "id": "crd3-label", "type": "text", "x": -106.65156286703723, "y": 405.8578330183359, "width": 128.62799072265625, "height": 15, "text": "TriggerAuthentication", "fontSize": 12, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#862e9c", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1231, "version": 270, "versionNonce": 1842960802, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "ao", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "TriggerAuthentication", "autoResize": true, "lineHeight": 1.25 }, { "id": "crd3-sub", "type": "text", "x": -106.77274215835354, "y": 423.95418596154525, "width": 102.9100112915039, "height": 12.5, "text": "Secrets / credentials", "fontSize": 10, "fontFamily": 5, "textAlign": "center", "verticalAlign": "top", "strokeColor": "#868e96", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1232, "version": 328, "versionNonce": 1585567074, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "ap", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Secrets / credentials", "autoResize": true, "lineHeight": 1.25 }, { "id": "arrow-metrics-back-label", "type": "text", "x": 393.421875, "y": 355.9140625, "width": 79.89599609375, "height": 15, "text": "Fetch metrics", "fontSize": 12, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1301, "version": 259, "versionNonce": 1680136482, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "as", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Fetch metrics", "autoResize": true, "lineHeight": 1.25 }, { "id": "o5AIWHv-1YltESqUftZiA", "type": "arrow", "x": 380.0259850132613, "y": 389.87109375, "width": 0.022045476656728624, "height": 65.64453125000006, "points": [ [ 0, 0 ], [ -0.022045476656728624, -65.64453125000006 ] ], "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1748185984, "version": 358, "versionNonce": 1376323810, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332454181, "startArrowhead": null, "endArrowhead": "arrow", "index": "at", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": { "elementId": "apiserver-box", "mode": "orbit", "fixedPoint": [ 0.5001, 0 ] }, "endBinding": { "elementId": "metrics-sub", "mode": "orbit", "fixedPoint": [ 0.5001, 1 ] }, "moveMidPointsWithElement": false }, { "id": "l-RzpLZG5U4qgeqgnbrn-", "type": "text", "x": 93.02102152506507, "y": 596.6302083333333, "width": 223.15798950195312, "height": 16.25, "text": "Scale up / down (0 → 1 and 1 → 0)", "fontSize": 13, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#e67700", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 840235999, "version": 230, "versionNonce": 238118114, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "au", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "Scale up / down (0 → 1 and 1 → 0)", "autoResize": true, "lineHeight": 1.25 }, { "id": "qs6l3Ff7lzQJs220D4VYv", "type": "arrow", "x": 164.0091789830321, "y": 319.01953125, "width": 215.8908210169679, "height": 302.8515625, "angle": 0, "strokeColor": "#f08c00", "backgroundColor": "#ffec99", "fillStyle": "hachure", "strokeWidth": 2, "strokeStyle": "solid", "roughness": 0, "opacity": 100, "groupIds": [], "frameId": null, "index": "aw", "roundness": null, "seed": 2090619776, "version": 1555, "versionNonce": 1976792786, "isDeleted": false, "boundElements": [], "updated": 1774108956031, "link": null, "locked": false, "points": [ [ 0, 0 ], [ 0, 267.91212661074564 ], [ 215.8908210169679, 267.91212661074564 ], [ 215.8908210169679, 302.8515625 ] ], "startBinding": { "elementId": "operator-sub", "mode": "orbit", "fixedPoint": [ 0.23699360895861515, 1.1875 ] }, "endBinding": { "elementId": "deployment-bg", "mode": "orbit", "fixedPoint": [ 0.4997222222222222, -0.05 ] }, "startArrowhead": null, "endArrowhead": "arrow", "elbowed": true, "fixedSegments": [ { "index": 2, "start": [ 0, 267.91212661074564 ], "end": [ 215.8908210169679, 267.91212661074564 ] } ], "startIsSpecial": false, "endIsSpecial": false }, { "id": "yHEaIHsM4npDrCzsg6leR", "type": "arrow", "x": 383.04077697349504, "y": 756.9544270833333, "width": 0, "height": 44, "points": [ [ 0, 0 ], [ 0, 44 ] ], "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 862921600, "version": 7, "versionNonce": 1290817214, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419184, "startArrowhead": null, "endArrowhead": "arrow", "index": "ax", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": null, "endBinding": null }, { "id": "HjCxtbTJ1WaKIcEEZiiYh", "type": "arrow", "x": 393.2207808813599, "y": 751.2421874999999, "width": 136.22970413643128, "height": 34.74519853968479, "points": [ [ 0, 0 ], [ 136.22970413643128, 34.74519853968479 ] ], "strokeColor": "#2f9e44", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 0, "opacity": 100, "angle": 0, "seed": 735818880, "version": 783, "versionNonce": 968083198, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419184, "startArrowhead": null, "endArrowhead": "arrow", "index": "ay", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": null, "endBinding": { "elementId": "podn-box", "mode": "orbit", "fixedPoint": [ 0.7658586849103699, 0.2341413150896301 ] } }, { "id": "Dg1JH1y9woiD2txdgGma3", "type": "arrow", "x": 70.99159888805241, "y": 283.642578125, "width": 29.172549153263958, "height": 1.2489801951611526, "points": [ [ 0, 0 ], [ 29.172549153263958, 1.2489801951611526 ] ], "strokeColor": "#1971c2", "backgroundColor": "transparent", "fillStyle": "solid", "strokeWidth": 2, "roughness": 1, "opacity": 100, "angle": 0, "seed": 888328854, "version": 386, "versionNonce": 1742616382, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419184, "startArrowhead": null, "endArrowhead": "arrow", "index": "b02", "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "startBinding": null, "endBinding": { "elementId": "keda-bg", "mode": "inside", "fixedPoint": [ 0.0008757994215650332, 0.3900022377090555 ] }, "moveMidPointsWithElement": false }, { "id": "trigger-block", "type": "rectangle", "x": -27.054389394302518, "y": 258.08128586240383, "width": 64.2333970397126, "height": 21.304687500000018, "strokeColor": "#e67700", "backgroundColor": "#fff4e6", "fillStyle": "solid", "strokeWidth": 1, "roughness": 0, "opacity": 100, "angle": 0, "seed": 495940736, "version": 641, "versionNonce": 2144378750, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419184, "roundness": { "type": 3 }, "index": "b10", "strokeStyle": "dashed", "frameId": null, "link": null, "locked": false }, { "id": "trigger-block-label", "type": "text", "x": -19.00167088642003, "y": 262.42592769166896, "width": 50.83985137939453, "height": 13.596450985423036, "text": "trigger(s)", "fontSize": 10.87716078833843, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#e67700", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 9902, "version": 628, "versionNonce": 641104034, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "b11", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "trigger(s)", "autoResize": true, "lineHeight": 1.25 }, { "id": "2MyjQA5BDQ7l3ZhNLjfFd", "type": "rectangle", "x": 215.56120816561463, "y": 241.99358053992373, "width": 52.905088521114635, "height": 18.812459625908406, "strokeColor": "#e67700", "backgroundColor": "#fff4e6", "fillStyle": "solid", "strokeWidth": 1, "roughness": 0, "opacity": 100, "angle": 0, "seed": 1033884800, "version": 892, "versionNonce": 233920510, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332419184, "roundness": { "type": 3 }, "index": "b17", "strokeStyle": "dashed", "frameId": null, "link": null, "locked": false }, { "id": "oM53NNNCpiF1kfQHe89eJ", "type": "text", "x": 223.46968414952528, "y": 244.3893088205931, "width": 36.536685943603516, "height": 13.673909505208304, "text": "scalers", "fontSize": 10.939127604166643, "fontFamily": 5, "textAlign": "left", "verticalAlign": "top", "strokeColor": "#e67700", "backgroundColor": "transparent", "fillStyle": "solid", "roughness": 1, "opacity": 100, "angle": 0, "seed": 1753481190, "version": 710, "versionNonce": 1810044002, "isDeleted": false, "groupIds": [], "boundElements": [], "updated": 1773332473877, "index": "b18", "strokeWidth": 2, "strokeStyle": "solid", "frameId": null, "roundness": null, "link": null, "locked": false, "containerId": null, "originalText": "scalers", "autoResize": true, "lineHeight": 1.25 }, { "id": "QqNXFuLZrly8QpmmjaPyO", "type": "arrow", "x": 190.33854776924233, "y": 319.01953125, "width": 43.661452230757675, "height": 224.87656249999998, "angle": 0, "strokeColor": "#f08c00", "backgroundColor": "#ffec99", "fillStyle": "hachure", "strokeWidth": 2, "strokeStyle": "solid", "roughness": 0, "opacity": 100, "groupIds": [], "frameId": null, "index": "b19", "roundness": null, "seed": 1979466210, "version": 205, "versionNonce": 731151634, "isDeleted": false, "boundElements": [], "updated": 1774108926232, "link": null, "locked": false, "points": [ [ 0, 0 ], [ 0, 224.87656249999998 ], [ 43.661452230757675, 224.87656249999998 ] ], "startBinding": { "elementId": "operator-sub", "mode": "orbit", "fixedPoint": [ 0.4284492900755477, 1.1875 ] }, "endBinding": { "elementId": "hpa-box", "mode": "orbit", "fixedPoint": [ -0.02142857142857143, 0.49843749999999964 ] }, "startArrowhead": null, "endArrowhead": "arrow", "elbowed": true, "fixedSegments": null, "startIsSpecial": null, "endIsSpecial": null }, { "id": "ZwiT9E6IrQnINiKxd8tMT", "type": "image", "x": 311.8969631105767, "y": 170.03737075137064, "width": 131.55859375000003, "height": 131.55859375000003, "angle": 0, "strokeColor": "transparent", "backgroundColor": "#ffec99", "fillStyle": "hachure", "strokeWidth": 2, "strokeStyle": "solid", "roughness": 0, "opacity": 100, "groupIds": [], "frameId": null, "index": "b1A", "roundness": null, "seed": 417457422, "version": 211, "versionNonce": 1397626510, "isDeleted": true, "boundElements": null, "updated": 1774109137781, "link": null, "locked": false, "status": "saved", "fileId": "65e649e8b30930959214e72e6503ca4f59ec309b", "scale": [ 1, 1 ], "crop": null }, { "id": "op_WEJxPCGy8DycY9YV08", "type": "image", "x": 337.4829006105767, "y": 224.05636489199568, "width": 86.30859374999986, "height": 36.46538085937494, "angle": 0, "strokeColor": "transparent", "backgroundColor": "#ffec99", "fillStyle": "hachure", "strokeWidth": 2, "strokeStyle": "solid", "roughness": 0, "opacity": 100, "groupIds": [], "frameId": null, "index": "b1B", "roundness": null, "seed": 313019150, "version": 329, "versionNonce": 2074691598, "isDeleted": false, "boundElements": null, "updated": 1774109206950, "link": null, "locked": false, "status": "saved", "fileId": "7dc7962598139e9d368782eedcc19347aae45b5c", "scale": [ 1, 1 ], "crop": null } ], "appState": { "gridSize": 20, "gridStep": 5, "gridModeEnabled": false, "viewBackgroundColor": "#ffffff", "lockedMultiSelections": {} }, "files": { "7dc7962598139e9d368782eedcc19347aae45b5c": { "mimeType": "image/png", "id": "7dc7962598139e9d368782eedcc19347aae45b5c", "dataURL": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAFSCAYAAAAKBbuLAAAAAXNSR0IArs4c6QAAAERlWElmTU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAADIKADAAQAAAABAAABUgAAAAAOTt+bAABAAElEQVR4Ae29a5Ac2XXnd29mdVWjGw00AIIcPLjqEcGxPLC44IC2wo6w2ROxYVsRVgiUYtarR5gN20H5wwyJMRlhW/YagP3Bu7ESB+RMbHjl8A4kWtJaQ3Ig0WsxZJHTQ1KWuCJAkBZmxeGIaEoAmhSIQePRXa/Me31uVlWj311VXY+8mb8keyorK/Pec3830V3/PPecoxQbBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQCDXBHSuRy+D/8Cz89MmMNOp4WCDuSsvHrqYGnt2aMiJM9cnA1M8s8Nmhn75lU8fOTd0IzYwIHX37wY2cmgHBFL4+yA395ywD6yac7MXFdTc1QuHkn33ng0CvhN46rlbZ5S2k+2MwwTBRe7/dkhxTicECp2cnMVzE/Fh9dm0jM0qOyu2XEyLPTu1I4xKr1mtTuy0neFer08Pt//Ne0/b/bu5pXzSDYE0/j7Izz1nlWk+ogtipeQLm5vCBavUVa3snNLq+4EJZhEn3dzZXDNMAslDBGVfUPLHuZ0tiM2PyXmp/TvYzhg4J30Eci9A0jcl2bHoqeduvix/rL0XH1nySGXn7mIkEBgKgUn5yjatRH0o+eVmtD3bFCcNYaLt6w1RUrl69cLjC0OxkE4hsA0BebDxwjanrPlYz8hqhue5p9dg4e2OCCBAdoSPizcj4MSH/JGe2exzT45fQHx4MlOYCYHhEmgIE6unG6KkpE4+e+uqDezvO0HyjZcOzQ7XPHqHQIPAU8/Nz4gA6fjBYHMp9Tk4QqBXBBAgvSJJO8sEnvrozXPi2p1ZPuDljr145cUjz3tpOkZDAAJDJ5AsPbX6hBMksnxLvCH2klLB6yasXOJJ8tCnJ8cG2LNdDd7qj4kX5AL3blf0uGgDAsEGxzgEga4JuKcrIj66+wXXda+9vdAqNSvig/WuvcVKaxDIM4HJhkfYvhzEpbvOQyweklN5BsLYB08g+fus1FSXPWcioUyXY+eyPhBAgPQBal6bbPxysy/7PH5t1VUbVj/k8xiwHQIQSDsBPSMeklfFMyJi5NYLJ87MT6XdYuzLAoEuvR+toYsXpLXLKwR2SgABslOCXJ8QOHHmxglZYuC1+JCBzMWF6tO4mLmpIQCBAREQz4g6E8T2+vufu/Va8wn1gLqmmzwR2KH3o4Vqknu0hYLXnRJAgOyUINcrJz6COHjNcxQLJjQfQnx4PouYDwFPCUherWn3EEc8Itfl54yroeTpUDA7lQR26P1YHlOv2llukJ2cEkCA5HTiezXsFeLD5z+WTnyI5+Po1V5xoR0IQAACXRKYkutekFiR6y6hB0KkS4pctkygR96PVntTeEFaKHjdCQEEyE7o5fxa94cxjAK37Mpn8SHFYNVpxEfOb2aGD4H0EZh0CT0QIumbGP8s6rXXotft+UcUi3dOAAGyc4a5bKEhPrJR5fzyS4cv5XISGTQEIOADgZYQ+SZPnn2YrnTZ2GPvR2twU2Rxa6HgtVsCCJBuyeX8Oh2XXk3y3PvMQdvzFBr0eQKxHQK5IjDlYkTki983P/Ds/HSuRs5gd0CgP94KoxUZsXYwK1wqVZGAAIFOCbgc9o2AyU6vTNP5Umjw00fOpckibIEABCCwHQH34EeKG0rGrJsvEx+yHa18f94n70cC1X0HQAjn+/7a6egRIDslmLPr3R+9RkEtnweeVDk/7fMIsB0CEMg7AT2TxIdIxqy8k2D8mxHoj/ej1Vus+9t+qx9es0kAAZLNee3LqFxqSN/Fhys0aMLa830BRKMQgAAEBkvAJQB5wdUQoZjhYMGnvTeXQU1snOqnnc4L0qgB1s9eaDurBBAgWZ3ZHo+r6cp9ocfNDrQ5Jz4oNDhQ5HQGAQgMgID7IijFDL9JYPAAYHvQRbI0b0BVy4OY6uge3BKpNBEBksppSZdRDfHhfZXzhbigKTSYrlsLayAAgd4RmJT4kFeJDekdUF9bCkzRLctz3rEBbHoG79sAMGewCwRIBie1l0NquFet154P4dEsNHhorpdsaAsCEIBA+gjomTAqyZKsGyfSZxsW9ZvAIL0frbEEsTnb2ucVAu0SQIC0SyqH52WkyrmiynkOb16GDIEcE3CZsoI4kExZ8zM5xpDLoQ/W+9FCjBekRYLX9gkgQNpnlasznUvV/QGTQQ/IjdsvvJoq5/1CS7sQgECaCcjvbvuyJA/x3YOdZsapsm0Y3o8WgMCYmdY+rxBohwACpB1KOTvH/RILI/uqDNt78UGhwZzdvAwXAhBYS+CMiJBXky+naz/hfaYIDMf70UQoQe/cY5m6nfo+GARI3xH71UFDfJRecy58vyxfa62r9XHo4tqjvIcABCCQQwKnGnEh1z1/qJTDmWtzyMmX/wFlvtrEpMmmANrkYw5DYDUBBMhqHrl/J4WtXs6G+DhyOveTCQAIQAACTQKNuJDSNwlOz+YtMVTvRwspXpAWCV7bIIAAaQNSXk5pVDlXp3wer6v1ceVFxIfPc4jtEIBA3wgksX2IkL7xHUrDKfB+tMY9KQ8xZ1pveIXAVgQQIFvRydFnDfGhZ3wecqvQoM9jwHYIQAACfSYgXxID0vT2GfIgm0+F9+PRgD/2aJc9CGxOAAGyOZvcfNJI1ei3+JDJmqPKeW5uWQYKAQjsjAAiZGf8UnN1irwfLSZTpH9uoeB1KwIIkK3o5OCzrFQ5l1ofVDnPwf3KECEAgZ4RQIT0DOXwGkqZ96MJwlKYcHi3hDc9I0C8mareG3ry2VsS72Ff7n3LA22xWeX86NWB9kpnEIAABPwngAjxeA5dvS413MxXm9HDC7IZGY4vE0CALKPI144LQpSsKL6LD5k0/fzVC4iPfN29jBYCEOghAURID2EOsqkgNs7TkMrUylbZDw+SBX35RwAB4t+c7dhiJz6yUuWcWh87vh1oAAIQgEBThFAnxJdbIfF+KD2TVnu1UtMfeHZ+Oq32YdfwCSBAhj8HA7XABaxlQnxoex7xMdBbh84gAIFsE5ikWKE/E9z0fqTa4FgTC5LqCRqycQiQIU/AILt34sP9gZE+U+mybZ+FVDn/9JFz7Z/PmRCAAAQgsB0BV6xQx6VXtzuPz4dLIO3ejxYdvCAtErxuRAABshGVDB5riQ//q5yrSxQazOANypAgAIFUEHBfGptFaVNhD0asJ+CD96NltdGWuiAtGLyuIoAAWYUju2+CuPiC7+LDFRo0YfV0dmeJkUEAAhBIAwE9Qy2HNMzDeht88X6ssPxUw+YVR9iFgBBAgOTgNshSlfOrFx5fyMGUMUQIQAACQyZgX3AJS4ZsBN2vIeCT96Nluo82t2zntX8ECv1rmpbTQOCp5269IHbMpMGWHdiwEBc0hQY3AmiDOUl3OLvRRxzzn4Ash7nq/yj6PwKr1GwvegmsmvTdU9wLDs02XMKSV2X57vt58NNDqjtoKvEkxHZmB00M6VI9I7afv3rh0NyQDKDbFBJAgKRwUnplUrPK+ZletTekdlqFBueG1H+qu21mAruYaiMxDgJ9JvDNFw8/3esuXApREfeTNrAnrNUfFDHovAGTve4n5e1NBXHpZbHxQym3MxfmNTwJcid6uDW9IKc9NB2T+0QAAdInsMNutik+3B8Or7fA6g9dodCg13OI8RDwkcA3Xjo027T7Ust+9wQ6iNW0UvZn5Zi85kKQnHJ/T0h7LrM9xM1f70cLmpZYkOtSOJhl1C0ieX8lBiSDd0Cj+I/1XnxIlfPTK74EZHCmGBIEIOATAbeExH0Rv/Li4Q/Jzz5JjCGeAXtRxrDg0zg6t9XFg8xPdX4dV/SKQAbiKCYDUzzTKx604z8BBIj/c7hqBC5oUNLeZSCPuz7NE7dVU8sbCEAgZQQuv3Q4SQvuxIh7YGJ7FIuSsmE6cyZ1nIWHWikk24ZJDfGnZ9o4Nd2nWP0xVxIg3UZi3aAIIEAGRXoA/TjxkYkq5/JEEfExgBuGLiAAgZ4RcL+zXCyKCfXjTa9Iz9pOQ0MSeSD1QeZn0mBL3mwIYuuSyWRhwwuShVns0RgQID0COexm3FMFl7FE7PD86YITH0cIVBv2DUX/EIBAVwQay7SOnM6mEHFLsXiC3dWN0eVFjSXV6lSXl6fvMvGCpM8oLBoGAQTIMKj3uE/3ByGMSq9Js1M9bnqgzblCg4iPgSKnMwhAoE8EVgsRdalP3Qy6WXnQVczK0/hBs+uqv1jbs11dmN6LJvGkpXdyBmkZAmSQtPvUlxMfvueud+IjLlSf7hMimoUABCAwFAINIXL4Q5LR72n3e24oRvS0Uz3TfCrf01ZpbD0Bx9ktfVv/ie9HMieqfJ+QodiPABkK9t516qqc+y4+hIYUGqw+TXq+3t0XtAQBCKSLgMvoJ0Hr71fank+XZZ1bk8Gn8p1DGMAVGeY8hRdkADdQyrtAgKR8grYyz4kPybwys9U5HnzWLDRIbnAP5goTIQCBHRK48ukj50xo3u+zN8Q9lecL5A5vhG0uz673ozVwvCAtEnl9RYB4OvNPffTmueyIj6MZWJbg6Y2E2RCAwMAJXJXiqo0lp0kNkYH335sO+QLZG44bt5Jh70drwFMs5WuhyOcrAsTDeU+ePFmdgcA0LVVRER8e3oKYDAEI7JCAW3LaSLqhT++wqWFdzjKaPpHPvvejAS4HIqtPd0g2mkWAeDaPDbd3FgpCUWjQs1sPcyEAgT4QcPVD3JIsaXqhD833uUm8IP0AnJcv5m4pH16QftxBfrSJAPFjnhIrXaFBKXAlcR/ebxcoNOj9HDIACECgRwScJ1hEiI9ZsvCC9OgeaDWTF+9Ha7x5EVut8fL6iAAC5BGLVO+tqHKeaju3N84VGjz8/PbncQYEIACB/BBoxYX4F5yOF6SXd2nevpA7L0jj4WovKdKWDwQQIB7M0grxMemBuVuZeIlCg1vh4TMIQCDPBFxciAtO90yE4AXp0U2bN+9HC1sQUx29xSJPrwiQlM92o8p54JZdeS0+3B9UE1Z9DbZM+V2CeRCAQFYI+ChCrLIfzgr/YY4jb96PR6z1zIkz81OP3rOXBwIIkBTPckN8ZKfKOYUGU3yzYRoEIJAaAi0RIgbNpcaoLQxhGc0WcNr86OSzt045jm2enrnTgthkILNn5qalrwNCgPQV784a13Hp1WxUOTenER87uxe4GgIQyBcB9ztTAtM/JKP2IjsWy2h2dn/K3/oXdtaC71fjBfF9Bju1HwHSKbEBne+qnGfgaUizyjm1PgZ029ANBCCQIQIuMD2w2okQDzb3BfK610uFhwW5WVV+alj9p6XfwJiZtNiCHf0ngADpP+OOe3DiIwNVzpX7w0mhwY6nnwsgAAEILBP4xkuHZuWNF5kDg7g0s2w4Ox0QIJNYAsvqjyFiO7htPD8VAZKyCWx4PfRMyszqwhx9uvmHs4truQQCEIAABFoEJHX5Bdm/1Hqf4tePpdi2VJqG92PVtEwGpnhm1RHeZJYAAiSzUzvUgT1PocGh8qdzCEAgYwSaWQQXUj6sKWo6dDpDeD9WEcMLsgpHlt8gQLI8u0MZW1Jo0D2tY4MABCAAgR4RcEHpPsSDEIze/oTj/diQ1SRL+TbkkrmDCJDMTekwB+TEx5HTw7SAviEAAQhklUBzWWvKH/DoU1nl3/tx4f3YhClL+TYBk6XDCJAszeYQx+IKDSI+hjgBdA0BCOSCgCzFOi8DTfNSrElX0yIXk7GDQeL92BLeVJPPlifxod8EECB+z18qrHfiIy5Un06FMRgBAQhAIMMEGjWVdKqzYlltfzbDU9CjoeH92BokfLbm4/+nCBD/53DYI1hw4oNCg8OeBvqHAATyQsAl+XAPftI7XpZhbTU3eD+2orP8GV6QZRTZ3EGAZHNeBzWqZqHBx9O8HGBQLOgHAhCAwMAIaJVqL8gk2bC2uhV4ur8VndZnVtkPt/Z5zR4BBEj25nRgIzKhEc8HVc4HBpyOIAABCDQJuIB0q9RsWoEEBi/IRnOD92MjKhsfc3XRPvDs/PTGn3LUdwIIEN9ncGj269OIj6HBp2MIQAACKrTaBaSnctNGEweyZmYaVb7xfqzBsuXbWMNrS0Aef4gA8Xjyhme6Pk2hweHRp2cIQAACjkCavSBWqxONL9zMVYtAs8r3VOs9r9sTwAuyPSNfzyj4ajh2D43ABcTH0Niv6/jEmfmpQqSm1n3AgaEQiAqVqyRkGAr63HYqsSC/qZSdTiOAMCo5uy6l0bZB25SIsVhnpL6FLP5TIg0GtBltHbfZAXVHNwMigAAZEOhsdJMUGkx1+sdscG5/FIExM0brs+1fwZn9JFCIRp+W9mf72QdtQ2AlAfdA6Knnbr0gxyZXHk/Dvg3sCbEDASIQmt6P1M1Rd/eJEx8DFSGn3MO2qxcOzXVnL1elkQBLsNI4K6m1SX8rtaZhGAQgAIH8EriYxqFbqz+YRrsGbVPi/bBZ8X606A3OA+J6DGLDg7YW+oy8IkAyMpEDGsZZ1vQOiDTdQAACEGiTgGQk/M02Tx3oafIVdXqgHaa0s2x5P4YFWc84L8iweqff3hNAgPSeaZZbnAziEk8hsjzDjA0CEPCOgMtImNbChHmvB5JN78dw/ongBRkO9371igDpF9nstnsm739Qsju1jAwCEPCVgMRb/H4abQ/i0MWB5HbD+9HLqdcSC3I9I3E0veTiZ1sIED/nbahW6zhwAY9sEIAABCCQEgImsOkM9tZmKiWIBm4G3o+eI59sCrqeN0yDgyeAABk8c+97dOt6m9VcvR8LA4AABCCQBQLNwrBzaRtLngPRffV+TOxK8VdDCebHC5K2f+Xd2ZPiu6y7AXHVoAjYF/glMCjW9AMBCECgHQJ2tp2zBnmOPLCaGmR/aenLV+/HyfcW1S9Oj6cF40Z24AXZiIqHxxAgHk5aSkzml0BKJgIzIAABCDQIBK+nkMRUCm3qu0m+ej9+5acn+s5mxx1kLqXxjol42QACxMtpS4nRVktaXtLipWQ2MAMCEMg5ARPGV9OIIG9/J3z2fpw8VlTfeKuaxttopU2TLANficPPfQSIn/OWGqt1bF9OjTEYAgEIQCDHBJpxIKkjUIjytQzLV+/HuV9qJJh6sGRTdw+tN8hSEmA9FK+OIEC8mq70GSvre6dPPnvrVPoswyIIQAAC+SMgXx1n0zZqo/MjQBJvj6wOSNscbGfPz/zULnV4f5ic9ubN+nanp+HzKbwgaZiG7m1AgHTPjiubBKxWpOXlboAABCCQAgJa2bkUmLHahByl4vWxWJ7LevXxn9uTzNmtt+PVc5fqd3hBUj092xiHANkGEB+3RWDqqY/ePNfWmZwEAQhAAAL9I6DV9/vXOC1vRaAR66JntjonjZ+5rFet1LvzXgkQNfWBZ+en08gUm7YngADZnhFntEMgyc1NQHo7qDgHAhCAQL8IaKPTF4hu1Y/1a7xpatdH74dbdvUL02PLGC9/t7a878NOrPGC+DBPG9mIANmICse6ITAZxJalWN2Q4xoIQAACPSKglV7oUVM9a8YqPdWzxlLakK/ej49I2t2W98OhfVA2KSW8sVkuDhUvyMZs0n4UAZL2GfLLvlP8IvBrwrAWAhCAAAR2TsBX74cLPl+5fcePAPSVJiu8IKtwePMGAeLNVPlhqFV4QfyYKayEAASySOAbLx2azeK40jwmX70f5365kXZ3Jdv5Oz4FoTcsd16QE2dunFg5DvbTTwABkv458spCyYh14qnnbp3xymiMhQAEIAABCHRJwEfvx8n3FpUrOrh28ysL1iPrg1h/7NE79nwggADxYZb8s1EqpF9f/2jFv3FgMQQgAAEIQGBTAr56Pz7RTLu7cmCe1P9YafKKfT3TmIsVh9hNNQEESKqnx1vjJCC9SEC6t9OH4RCAAAQg0A4BH70fLu7jiSMj64b3oCxlLD3efJwLj3Hv2HQEyI4R0sDGBNzTCNZkbsyGoxCAAAQg4DsBH70fLuOVy3y10eZbCt71Y8ALsp5Jeo8gQNI7N95bpuMAL4j3s8gAIAABCEBgIwI+PnF3RQdd7Y+NNt9S8G40hsCYmY2Ocyx9BBAg6ZuTzFjkMlM89dz8TGYGxEAgAAEIQAACQsBX78fKooNrJ9LHFLxrx6CSosjEoK7jksIDCJAUTkq2TLIvEJCerRllNBCAQHoJEIg7mLnRsX15MD31rpeP/PTuVUUH17bsYwretWOQ95OBKZKJcwMwaTuEAEnbjGTPHglIL53N3rAYEQQgAIH0EShEaip9VmXLIldw13n4fRqVW3blll9ttfmagnfdmPCCrEOSxgMIkDTOSvZsOsNTuexNKiOCAAQg0A4B+bK+0M55vpzjY+Xtj2+Qdnclb79T8K4cSbLvHnzOrDvKgVQRQICkajqya4yP7urszgYjgwAEskrABGY6dWPT9lups6lLg3z0friig9PvG91yxLc8rIC+5YCUojDhNoCG/TECZNgz0Lv+53rXVO9bcu7qk8/eOtX7lmkRAhCAAAQgMBgCPno/fmWTtLsrib15M1r5Ngv7UyTBSfc0IkDSPT9tWmcvmrD6fjk51W5uqxUB6W3OKKdBAAIQ6IaAtfqD3VzX12usTvXfpnbH7qP3wxUdPHmsuO0Qb72dOQEiY7bEn24788M7AQEyPPY96tlevPLikdNXLzy+oLT9VI8a7VczU2Sn6Bda2oUABCCglHibT6SNQ2D11bTZ1I09Pno/Nis6uHb8mQlAXz0wvCCreaTqHQIkVdPRqTEN8dG66sqnj5yT/bnW+1S+Jtkp5qdSaRtGQQACEPCYQDPl+aTHQ0it6T56P9zSq82KDq4F/eaNLHpAxAei7IfXjpX36SCAAEnHPHRhxWrx8agBff7Rfir3JDuFpUJ6KqcGoyAAAZ8JhFFpOo32f+OlQ7NptKsTm3zzfkzsCtRWRQfXjj0LVdDXjsm9d/GnTjxu9BnHhksAATJc/l32vpn4UOrKi4cuWqVmu2x4UJed4hfCoFDTDwQgkBcCEmf3wRSO1fv4Dx+9H67mhxMh7WyX36q1c5q35/gmHr0F3aHh7d2dHTbK6f0ksLn4aPUa2tR7QZTR/lWRbfHlFQIQgEAaCWirptNmlzwQ8z7+w7cvsG7Zlat63u72YMm0e6qX5+EFSee0IUDSOS+bWLW9+HAXNtzd9uImjaTlsASH3TqTFmOwAwIQgIDPBFz8h3hATqRtDFrZubTZ1Ik9Pno/2g08b3HIYAre1tCWX402H15+w04qCBRSYQVGtEGgPfHRasiEwXmJtZhpvU/p61n5o3kxyeCVUgPTbpYJgouFKPVL7tKOsWf2RYWK9097ewaDhgZKIIhHT7mQ2/Rt2usihM77IU/Qvdlc0UGXereTLZspeNcS0DMnzsyfv3rh0NzaT3g/HAIIkOFw77DXzsSHa9z9I3vqozfPK6vPdtjZIE+XgPSiC0g/PchOs9RX85fpXJbGxFggAIFuCNif7eaqfl/jcwreRiE7O91vRr1sv52ig2v7y2gK3rXDVEFs3Pchvm+sIzOcAyzBGg73DnrtXHy0GjdB7YLsL7Tep/NVzxCQns6ZwSoIQMAPAs30u+IBSd/mt1fQr0J20+8bbavo4Nq7JKspeNeOU3JiOS/I1PrjHBkGAQTIMKi33Wf34sN10VzadL7t7oZ0ouTpJi3vkNjTLQQg4D+BxvKr9I1DguKv+rrEtuH9UFPpo7q5RR//uT2bf7jFJ1lNwbvRkJtekI0+4tiACSBABgy8g+4uuQrnHZy/4alXXjzsvCBzG36YkoMucLL5yz4lFmEGBCAAAX8IaGs/lkZrrbZX02hXezYNw/vRfQyPi/tot+jgyvFnPQXvyrE29vWppsdw/UccGSgBBMhAcbfXmXtqZMLqjsVHqzdp7/nWfnpf7Qv8Ukjv7GAZBCCQTgInztw4kcbsVw1awevppLa1VcPzfuitDdvkU1fvo1vvx6078SatZvbwZGCKZzI7Oo8GhgBJ32TNxYXq0710W19+6fAlea4ym76hrrJIAtJLaQ6YX2UsbyAAAQikgUAQ61R6PxwbE6b+784mU+iX96OTooNrBzz/du4EiCSL0x/jgefaO2Hw7xEgg2e+ZY8iFOZ6KT5andnQeOAFUWfc07yWzbxCAAIQgMDmBBoBtXpm8zOG+on8LfMv5alv3g+37OoXpse6nujv3Kx3fa3HF+IFScHkIUBSMAmDMOHqhaOyFjf1xQmVjgMC0gdxQ9AHBCDgPYHAmJn0DsLOpte2rSwbhvdjK3u2/swVHXRLsLrd8hSAvoqR1R9e9Z43AyfQ/V07cFPpcKcEXHFCaWNhp+3083pZATt98tlbp/rZB21DAAIQ8J1AsoRElpKkdxz+xX8Mz/vR3Sw+cWSk46KDa3u6/N3a2kN5eT9F8pvhTjUCZLj8B9p74g7X9lMD7bSLziSgkoD0LrhxCQQgkB8CzSKuk2kdsQkrl9Jq2+Z2+eX9+MTPd5d2tzX+3Ho/WgCUX/O9bHZGdhAgGZnIdofhR3FCNUWWinZnlPMgAIG8EUh57Iebjkv9iGXs5zz75v04+d5iV0UHVzJ882a08m0e9/GCDHHWESBDhD+Mrht/FHT6A9KtPkvF0mHcIfQJAQiknYCO7cspt9HD9Lt+PQ3/RJdFB1feNzlMwbty+M19v+Z9gwF4ewgB4u3UdW/4lRcPXXS1RrpvYTBXBjEV0gdDml4gAAFfCLgYORcrl2Z7Tai9Wn41HO+H5LzscnNFB138x063XKbgXQ9t6gPPzk+vP8yRfhNAgPSbcErb18oDL4hSp/jFkNIbCLMgAIGBE3CB5xIjl3bvhyy/8if9bqMexDAedomM7GJzGa9c5qtebDlNwbsOXazxgqyDMoADCJABQE5jF9946dCsPH+ZTaNtK20yOvVLDVaayz4EIACBvhGQYq1OfKQ28LwxcP37fQPQh4ab8YYDZtq998MVHXS1P3qxEYTeoOg8ijzs7MUd1VkbCJDOeGXqbBvq0x4MaOqpj94854GdmAgBCECgbwSeeu7WGWn8VN866E3DCz5lvxpeKuPuvR87KTq4dopznIJ3LQqFF2Qdkr4fQID0HXF6O2i4ydNfnFBJrnsC0tN7H2EZBCDQXwInztw4IT2c7W8vvWjdepX9ajjej+45f1wCz3dSdHBlz3g/VtJQynlB+J6xmkm/3yFA+k045e2bsOYyYi2k3MzJIDYe/PFNOUXMgwAEvCPgntIHcfCqGD6ZduNNmP46Uy2Gw/N+tCzo7NUtu3LB573aSMG7niTfM9Yz6ecRBEg/6XrQdpKW14PihPJ8YoY1mh7cUJgIAQj0lICOS058TPW00T405jIrXr1w9Gofmu5Lk755P879cm/153du1PvC1e9G9QxekMHNIAJkcKxT21OzOOFcag1sGmbVMDKVpJ0K9kEAAlkl8NRzN192S0N8GJ/V+lM+2Ols9M370Yuig2vn5mG5+0D4tW1l6T1ekMHNJgJkcKxT21OzOOH51BrYNEzST55oBmKm3VTsgwAEILAjAk58OM/vjhoZ3MULrr7U4LrbWU++eT9+pUdpd1dS+8Zb1ZVv2V8mgBdkGUWfdxAgfQbsS/Puj4c8D5n1wF6pkH69t75oDwaNiRCAQH4INB60eCM+RCcR+7H13dm9t8HFfZw8Vty6+S4+fbDUvU1ddOfVJYExM14Z7KmxCBBPJ64fZodWp94LIuOWgMzS2X6MnzYhAAEIDJtAM+34C8O2o5P+TRBc7OT8YZ47HO+HLKTrcutV0cG13b95kxiQtUyW3yeZN3nQucyjTzsIkD6B9bFZV5xQ7L7kge1nmmkpPTAVEyEAAQi0RyBZdmW1Zw9Y7EVfKp/7Fvvhll71qujgyjvw1tvxyrfsrycw2RSq6z/hSM8IIEB6hjIbDZlQu7S8qd90HHj1hDD1QDEQAhAYKgHPYj6WWZkw8MFzntg7HO/HMqqOdly9j14WHVzZ+TwCZCWOjffxgmzMpYdHESA9hJmFpppPsi6kfSzi0J5+6rn5mbTbiX0QgAAEtiLgnsqffPbWNz0KOF8xHLwfK2D0dPcjP727Z0UH1xpGCt61RDZ8L8u9R09t+AkHe0IAAdITjNlqxIRV90RrIf2jsgSkp3+SsBACENiEgFtKKjFt112Gv01OSfVhr7wfjdjByVQDbRrnll394vR430wlBW+7aK1nyyHbHVc6zkOApGMeUmVFIy2v8sGtPsU6zVTdOhgDAQi0ScAFm0uFc/F8pL/C+SZDuuBP7Mf8lIzhzCbjSN3hfgWetwZKCt4WiW1fp1hpsS2jrk9AgHSNLtsXXnnx8AUZ4VzqRykBm1QuTf0sYSAEINAk4H5fvf+5W68p74LNV03hQtNTvupgWt/4VFzOFR10qXf7uZGCtxO6eEE6odXJuQiQTmjl7FxtlScB6fblnE0Nw4UABDwk0PB62G+6GDYPzX9kstT9aHrKHx1L6V7jAZWeSal568zqR9HBtZ2QgnctkS3f4wXZEk/3HyJAumeX+Ssvv3T4kvWgOKH7Y/6BZ+enMz8hDBACEPCSgPv9JMUFrze9Hl7EIWwBeu7Kp4+c2+LzVH3kk/dj+n2jfSk6uHJCSMG7kkZ7+1bZD7d3Jmd1QgAB0gmtHJ7rSXFCZTRekBzengwZAqkm4ISHW24lv59eE0OnUm1sm8YFVp9u89ShnzZ474c8stvB9vGf27ODq9u7lBS87XFaeRYPOVfS6N0+AqR3LDPZUqM4ob3oweCmmhWEPTAVEyEAgSwTWCk83JeX7IzVXmwWrPViSIP3fshsd7m5rFf9KDq41pzL362tPcT7NgjEmliQNjB1dAoCpCNc+TzZm1SLSeGgJNtJPieKUUMAAkMl4DLmtDwe2RIeCVYJPK95ERforPXJ++GKDrq6H4PYHpTNILrJXB94QXo/pQiQ3jPNXItJqkVtz3swMCkcZKmQ7sFEYSIEskLA1fKQ+I4X5OeuUvblDAqPZKokKclpXwLPncG+eT+cCBnE9p2b9UF0k8k+jDbEgvRwZgdzx/fQYJoaDgET1Fxa3oXh9N5Rr6cISO+IFydDAAIdEpDK5aeaouN6s5bHGWnC9+DyrShccElJtjohTZ8N3vvR/ejdsqtfmB7rvoEOr5y/E3d4Bac/IqBnGvfWoyPsdU+g0P2lXJknAu7JlywvEPd7+oO9JWOF84K8P0/zw1ghAIH+EHBfOMLInrCB/Fj9Qefh2FmocX/s7Fer4vm4GheqPnjAlxE0vB8yUx5srujgoLwfDgdZsHZ2UzQ9a6d31gpXOwIIEO6DtglcefHQRXnqd1YumGr7oiGcaLVySyLONIspDsGCwXXpvhwVonTPx+BoZK8nnwJ+h0m/F15PyVR1QmmbeDGc0HDjka+w0yqWRxqy4/7jXvK2xQXj1dKr5Al1bGd8mKcnjoz0vejgSg7U/1hJo9v9xAtyPlma3m0TXJcQQIBwI3REwKVgbKaU7Oi6IZwsFdKvX/RpzXI3jAJjZozWThSyZZNAHr/zdjyTPfudlCiNRHh0bEM2L9AiPo5e9WlsPnk/PvHz/U+7u3LuHpTz5LtbOfLe7uMF6Q1PYkB6wzE3rbgnsvIrbNaDAUtAepGAdA8mChMhAIE0ErAXndc7jZZtZlPDE6ZnNvs8TcdPvrfY96KDa8dLCt61RLp9r0/JA84sx3x1C6aj6xAgHeHiZEfAhsaTVIzOVXrjBLMGAQhAAALtE3BxH1dePHK6/SvScaZPtRrO/dLgv7+Sgrdn9+lkYIpnetZaThtCgOR04ncy7IZL3ovihErHAV6QnUw210IAAnkjMCdB50/7Nmjn/ZD1itM+2P0zP7VrIEUH17IgBe9aIjt4n9QdwwuyA4IKAbITejm+tlmQaiHtCNwfJFccLO12Yh8EIACBFBCQYoPmQz7Gzvni/XAZrz7+c4ON/WjdV6TgbZHoyStekB1iRIDsEGBeL0/+QGn7KT/Gb19gvaYfM4WVEIDA0Ag48fG0b0HnjpZP3o9fnB4faNrdlXcTKXhX0ujBvtUf7kEruW0CAZLbqd/5wJvFCed23lLfW+BJRd8R0wEEIOA3Af28j+LDMffJ+zHIooMr78fLb9VWvmW/NwSmWGHRPUgESPfscn9lw02vz3sBwmpJyzs/5YWtGAkBCEBgoAT0ad8yXrXw+OT9cEuvBll0sMXIvT5YMivfst8zApY0+F2yRIB0CY7LGgTcHy2XMcUHHjpOfxV3HzhiIwQgkCUC/ooPNwu+eD8O7w8HWnRw7R365s1o7SHe94YAXpAuOSJAugTHZY8ISH1gL9LyuoD0k8/eOvXIcvYgAAEI5JmA3+LDJ+/HuV+eHOqNduttBEj/JgAvSDdsESDdUOOaVQQ8Kk6opNAxAemrZo83EIBAPgn4LT7cnPni/RhG0cG19zQB6GuJ9PT9lBPDPW0xB40VcjBGhjgAAjbUp2WJ0/UBdLXTLqaaBYTO7bQhrocABCDgIYEFWTZ7+vJLhy55aPuyye4Ln1F2evlAinc+MaS0uyuR/MZzB1a+TcX+b/zhQ/XP/vBBKmzZqRFNMTy703bydD0ekDzNdh/HevXCoTlp/kIfu+hd00kBIQLSeweUliAAAU8IJKl2L7902Gvx4Vj74v1wRQefODLiye0xODNdVfbfmV0cXId97skt8cYL0hlkBEhnvDh7CwImrLqMWAtbnJKWjyaD2FIhPS2zgR0QgMAgCMz5WudjLRyfYj8+8tMTa83nvRD49c/fV06EZGnzRRSnhTkCJC0zkQE7/CpOqE7xtCIDNx1DgAAEtiXgMhXKA6L3+1rnY+0ArfLjAdKviPhw2a/YVhNw8Shf+Hp59cEMvHNeENL9tz+RCJD2WXFmGwSufPrIOTltro1Th36K0aTlHfokYAAEINBnAvZiXKhKhfPHffBOb8vCFX6TZCIntj1xyCe4eh/DKjo45KFv2/25387ErbjhOIPYUBdkQzLrDyJA1jPhyI4JeFKcUCnJ333rzI6HSwMQgAAE0kng+SsvHjmdFfHRQOxHytOP/PTuoRUdTOet2LDKVWS//N0sV2XXM3hB2rsDESDtceKsDgi44oRWqdkOLhnmqVIh/frkMA2gbwhAAAI9JrAQWP30lRcPX+hxu0Ntznk/xICpoRrRRudu2dUvTo+3cWb+Tvm1z93P/KDxgrQ3xQiQ9jhxVocEQuuNF0QC0osEpHc4v5wOAQikk4B7+CPxHo+7+kzptHAnVvnh/fh4CtLu7oRyv651cR9v3qz3q/kUtYsXpJ3JQIC0Q4lzOibQ+ONnL3Z84VAu0DMEpA8FPJ1CAAK9JfD8N188nJl4j5VofPF+uKKD0+8bXWk6+0LAZbz6jYzU/GhnQgNjZto5L8/nIEDyPPt9HrsJA5eW14uN9HleTBNGQgACGxBoZLky78/akqvVQ/XD++EyX7GtJ/C7s0sqV9XYk3pjLO9efyc8OoIAecSCvR4TSIoTauuFCHHp85pP2HpMgeYgAAEI9JGA/I6VwoKZSbG7EanBej9kEVuXm/N8nDxW7PLq7F6WtaKDbc7UZGCKJLnZAhYCZAs4fLRzAiaouSDIhZ23NIgW7AsEpA+CM31AAAI7JdCI9dCPN1Of77S5lF8/SO+HPI7qciP2Y2Nwv/GHDzNXdHDjka45ihdkDZDVbxEgq3nwrscEmukfvfCCyNAlIL10tscIaA4CEIBALwnMyZKrDzViPQ7N9bLhNLY1WO9H9wRc1iuKDq7n55Zd/c7s4voP8nFEvlOMnsrHUDsfJQKkc2Zc0SGB5rrkuQ4vG9bpZ06cuXFiWJ3TLwQgAIFNCCwoWW7lKprLkqtLm5yTwcOD9H50h88VHXR1P9jWE/j1z2c/7e76Ua88kv77d6W1g9xHgAySdo77kid2z/syfB0HpOX1ZbKwEwK5IGAvutS6brlVtooKbj15Pnk/nAhhW03AFR2c/XZl9cH8vZOCx0n9mvyNfJsR8y9mG0B83BsC7omdW7Pcm9b624oLSD/57C3cpv3FTOsQgMC2BJzwkDiPzFUz33bgzRPS//TYLbvC+7HxfP6zHKXd3ZhA62j67+OWpYN8RYAMknbO+7Kh8cYLYrUiID3n9yvDh8CQCCwotVJ4ZD/OYyPOTz1364wcn9roszQd+whpdzecDld08PJ3axt+lsODeEE2mHQEyAZQONQfAlcvHL3q/rD2p/WetzpFCr2eM6VBCEBgcwJzzRiPpscjn8LD4WlmI0x9QpAnjoyon/mpXZvPaI4/yVPRwXam2Sr74XbOy9M5CJA8zXYKxtosTihP+DzYrD574sz8lAeWYiIEIOAvgUsuq5Uk68hdjMdmU9Z8+DO52edpOf6Jn9+TFlNSZYfLepWrooNt0HdLuz/w7Px0G6fm5hQESG6mOh0DbRYn/FQ6rNneiiC2BKRvj4kzIACBzgjMyenPN+I7Dn8oX1mttgaVeD+kfsLWZw3/05PvLVJ0cINpcEUHXd0PtvUEYk0syEoqCJCVNNgfCAG/ihOqUzy1GMhtQScQyDQB8XLIElR1wYTm/Ym348XDF5IHMpkedeeD88X7ce6XUu+g6Rx+D6743dmlfBYdbIMdXpDVkAqr3/IOAv0n4NJISlo6CUi3L/e/t533YHRi5+M7b4kWIACBnBG4JON9XTwdlxAb28984v2I0+/9cHEfFB1cP59u2RWZr9ZzWXnEaONiQWZXHsvrPh6QvM78kMd95cVDF5tPBIdsSVvdTz310Zvn2jqTkyAAgbwSWLDui4UUCwysflq8HFp+XGwHno4274jBej9ktrrYXL2Pj/8csR8boSPwfCMqa4/pGWJLG0zwgKy9N3g/MAJa6eclM8RrA+twJx3JmmR5OidfJB5f2EkzXAsBCGSCwJx8fZ3T2r6ubDBnwvhqI8tfJsY2lEEM3vshC2K62H5xelxRdHA9OFd00KXeZdueQBCbs3LW6e3PzPYZCBD54yFfgmfTMs3yK9GtE87F9o2XDs0+9dzNi1bpKR8GHMSjp8TOiz7Yio0Q6BuBHfzOlN9vJ8Suyb7Z1oOGRVjMtprRykpqXPV99z4wQXLc/d5y79l6S2Cw3o/ubHfLrn5heqy7izN+FUuvOpngxAtyPu/LMuXvARsEIAABCEAAAhDIEwEpN3tO5OXsbHD84DuD0X375IHs6IgpVYtBYHfVld2lIj0eBnoisHbf33ln+Nj/+d8d/PWRgkaBbHCb/BefuvOPv/1XtevG2gUV6HtGhfeDeu1hrVBcLFWDpcp4paqqpdri0mI0PrVknrz2ZPzKcWVlDkTzy4JsttwRIAYkd1POgCEAAQhAAAK5JrD88HV6elpVHyvqejnQ8dg9XQ/KgYmUHom1DrUS7SHfjgOl/8l/uf8fID42vmf++Gpl9spbtflY6XIQqEpo5VXF1XoY1mwQ15Wq13dHY9FoFJnCRGQPqifNKxs3xdEcEUCA5GiyGSoEIAABCEAAAhs/cI+rgQiTccFTUdaId0S2MIj10z85evA9hwofhNt6AtW6rVx4deGrKlRLgVVlK+JDhIiIj6CmRuq1YhxFtbAel0v1+E6tavZWj5nZa+L1wPuxHmbOjiBAcjbhDBcCEIAABCAAASFw7ZVlT0iLh60vybFRpQNl3Y8sKTK/+p/ufbb1Oa+rCfzhN8qvzb8d35VFVBWrTUV0WzUypqZNXLPVQl18SfWxQi0ej+uJ92Pizdmm+ju/uiHe5Y4AAiR3U86AIQABCEAAAhBYSyAsGatHxmxQEPERWivrr8x///f3/1v7J4KfXHsu75W6v2QWzv+LB1+1KigLsbIxqhIEUUWFUU3FYa0U1aPxqBaVSxNx6W5k91bvmdmDt5vej7MiRNbpP7DmiAACJEeTzVAhAAEIQAACEGgSOP7M8lqskV3Ghkt77Ygxpm5KJrKyE5n4P/63d30UXhsT+MLXK18OjVmygSlro0V86Iogq+lYll/pSDDWo3rT+3F7cclMvPlgrfdjmf/GPXA0ywQk6wMbBCAAAQhAAAIQyCOBWVU6MG3VrXlVKFkbVSXsvLgoamSk/pn/dv/Pj5f0E91SufPA3KxGtqzM9i2sdAe4wHe5QrtXY408KNZBZJQsCJNs0OKY2VUMSkffEe7dvtX+nfE3t+O5T756/8/E0iVZfrXoXk2sK2GxWJH4mWo9COuBHq+X71TjpckHZu++stQ7EO/HK88YlUSgk/mqf7PjR8sIED/mCSshAAEIQAACEOgJAff9vvnwfVZ2D76hikf32PvV2Mj35lhHJcmDFQX/2a/98JXIjHwh0PVdQVgYNTYohbEtWW2LIgpG3I8JTKjdgi1lxAEQulVbjXVFUml32dTWseUDrZ1Hi1Cc2Ai0lLaUzFuuPbFvRFk7IodLUquspLXaJSaPSavjH/r3xn78f/gHe//dVivDeP2d15b+H6VMsvRK20JFcohVlS1UdaxqEjxTj6JqVB8P4sV31M27Fo+Zy3dFhh0/KQLEWYv4GMacpa1PBEjaZgR7IAABCEAAAhDoJwGnPhKBMHtw2p7cp+z83Tl7oBiaQml3bE05WIyL0chIFIRxpIOwqK1EVktQehQXrJQIMSPaBAXxTYjiCELxUoSiPsRjYRKvhRIh0dI3jUGInthkk8xRDaEiqX6NEzHSlBM1ytiiKBEROkFJcnM58RFLOmDRIkq/b2pkqLVInPfjla8tfkdEkyt9XlZBXDFaV7SKa5VA1cMRKyl3x2MzXzXV90R2Yq9YfVh+kpofm4DgcO4IIEByN+UMGAIQgAAEIACBFoGJw7P23p2jtlgoJF6QkeJ4PLpU1qo4op2fw9SllIUKYylMGEmdi5ookoKogTCMdGhEpBRiLTrCLZkS4RFETc/H9l+vCnJ+6+zAxlI6wzlBrOiOQEppiKdFPB8icEZjHceBHHDiQzwk4e4xsWKI29nPLPye2CK1PsJyrK1oDlUV50+tFupasV6NylEQ23IYL1bqZu+1KTPr3E3HWwbj/WiRyPvr9v9C8k6I8UMAAhCAAAQgkD0C7on8OSXF0JU++cQxM/9gTjsvSEWpSI3tUuGSPNwvVEVbFG01COKCqUla2bBQlzLfBVEJ4gEJjKzLcl4MJ0CkbKGoFVdLxG1bB37YUOt6JOeLwHE1RwJxoVgTiR9E5I30akR8SNOj0kqkrKzwkiVdssyrIK6V4tS7CvsbfQz+v9++Xvvm1e/VfihjFY+HeD0k9a6sO6uKx6Zm66P1eOxBNB7uj1S9EsePHTWjsjAL78fg58mHHhEgPswSNkIAAhCAAAQg0EMCTieIAHCbLMOaOCzlB+Vp/R15e0DNSylCFYVq1C5JXEg4Io6OYiUqxIVQJIJ4KZRbcSULspxHYkQEgxyJRXIUauKfSFpc8R9ZRbXBZuO6tCIfyHVOgIjQ0GFYCKIoKog/pRAqK8JDPnXLrmQdlizvKkinxdioUQmM37jRDfrp5SFXdPBTf/Dgj8SOsgikpOiguGoqsR6pRrVKvSTJwypxKYqXovje3djuPf6GnVBPNiE7S/B+9HI+fG8LAeL7DGI/BCAAAQhAAAKdEnBfjLV4QBpekGtKTR93bos31J25MRXJF+hQws6jkVEzMvrQFHUhqIkbpC6uipL8yAHJUCXfqAsVHdZ2KYkKkfVYje/akg2q4QUZdSbVNrRLh+5DkTnyf3ethK6LphFRI+4OqakxIqJEipLEKpTsV+JUGRGNU5Ij0r2N3jUZHtyw0T4f/Nq16p9e/avaDwRbQ3wEqhIbLYHnUnRQi2NIqp6PVsdFUlVM1Xk/bl22s3eF7yuJiOqzdTTvGwEEiG8zhr0QgAAEIAABCPSAgHsiL1EVToSo82pWnVXq+JPmZFHZiiSWvR/O2WhvwexeLMWLewIp8b0QTI6HOqrKMqtIItfH7rkFSPqhlq9SkQgJ+RreMEqa2yN78rL5tiSV/PaoePSBHi+L9CiJGIpFw4SidOqqLqJEwkmUlNRQoTZGsmBJbQ2l63/3x0bGN2+zf58478cLr95/TZadLYpfZlFGuiQxL+VYan/YuFpVxdGaeEEivUdH939UNQfUZcl8dVIyX50XASJc8X70b3I8bRkB4unEYTYEIAABCEAAAjsl0BQh6mwjUFo8IZfVK7L/jD55a8pWbih977G3dPQjCb9QpTiqlpoB4FLwe0mcEiJM1A/FjSFbKAEd8UQzBqTahl0lCZAol/S98UDvrWq9FC+G4YiUQhyJXC7euiqIJ8S5QSQAXkLTxSdizBPvHnHSZuDbFy9Xv3xrQRSY0WVZMFaRkiRVEUay5szUjHg/xqTquZaig0EcmKUfRvZyWYoOTosEOydcRVuxQWAtAQTIWiK8hwAEIAABCEAgRwSasQnnWi6LN5KxJ0LktgiRffckI9ZJVbn7hq4sTiXLtKqPFbV6y512LPm/24skiF2JY6OTLVos6HcVQl0vi4dlcsyWlqSBIApKpbG4Gts4lHLskhnLiQ8pQajV1MHCwAsQ3l8yC//zb9/7qoxrSRJ3VcRNIwJE3B1KIvRFfJRGKlFN2dgUJuL7PyrbA+++Z9RdKTooXiXlvErb+ILcCWz5I4AAyd+cM2IIQAACEIAABNYRSLwhclS+NLu4hXPPuEf39vK1k41H+Lf/Vl6flEPyc1tiRmTvwYPLWr1bdtRJSZY15XY62iqLb+h7f/Okruy+EeyV9UwjE1JwpLLLyJInSbwrP43aH869knyNP/yOcLKjDnpw8v/19cqXZIFZWUJekrofRup+SHR8TZII18RCif0oReXFQrx/b8XEi0vm8pzzfjzjYmtEhDTQ9cAMmsgYAQRIxiaU4UAAAhCAAAQg0C2BpjfEfXM+J6X2Glvj9dx089v0eTl6VmJGZHPi5K7b6WaTsuDiYTl+8I0gGh+zo9EPjcSWWKl9bl25QwlHf7TJQixX4PDIgcKRRwf7v3fjR/H1X//8/X8l2bjKkmW44jwgsVVVyRdclQTE9VItjCq2GJXq3zfzd/fYA/tc1qtrTfGR2Ndi2H9j6cErAggQr6YLYyEAAQhAAAIQGAAB+eK8/PReduRt8kTf9Xx2Zfc7+IL9hlbPyNf1fWV7rFS089XD6lBSXHxl87IvaXpFjCTpf0eLeteaT/v69jNfevhlWQJWkZRclVA7AWJEeEjshy7WJEFX3eyqReXavbjyjveZvTeUubwo1h4X74doK+G3AzZ9HRaNp4BAM5gqBZZgAgQgAAEIQAACEEgfAfki7b5M9/LHDTIJfLfqzZO29INjyZf1ljNFSg6K6EiiP1xtdOnYVVs3wcG9gVQsGcz2N+L9+OyflL8jkkIyXqmyRJtXTDAilc+DarkW1WPJuxvHu6KxhYl4NHrLHHRpIdJeVgAAIM9JREFUjI+7pWtOrbFBYGsCCJCt+fApBCAAAQhAAAIQ6DGB1d6BqmTaOiQ97JP/SY1CXYqrEt5dD0SDBJLyNvF+SAaqoFgYnAfk7Gfufj6J/RDPhyThEuEhRrnMV3FYKxbjqFSI4/L9KH77HXXjBNTstZXCY/X4egyP5jJAgCVYGZhEhgABCEAAAhCAgMcEXEYtCWaPa1JbpDCm46IUO3ReD6tl5ZORguNB8AtPj71nUCP8/+bqV771vfpN6U8qosRL1uglWQVWrteiqtGjtaD+oK7M/vruQiWOo6MN74dbp4b3Y1BT5H0/eEC8n0IGAAEIQAACEICAlwSuKX3yCcmkdeyYqktNkXiXVABxVdYLSpRHkHhAgoLsGBNIofWBfGdzRQc/den+H0u8h8R8SNyHLL8ST0ylHgc1q6J6KTJRLP+tFKL4h1IxvvSDN/B+eHnzDdfogdzMwx0ivUMAAhCAAAQgAIH0EnA1ROIlWehUC7QEmutEc8jSK6Oksl8k5UACHf7UT5R+fBAj+NpfVP/fb36vNu+qncv6r3IQiJtDsl7pUNLuysIwU4qi0XBc4j7+2ow+dtRc+3uSoZfYj0FMTab6QIBkajoZDAQgAAEIQAAC3hCQLFhJDZGWwXv2qMjFfcTNIHTZD1RBflQwVlRjrdP69eq8H5+8dP8rSeyHBJ1LCUQRH0bERyjiI6pbNVKviecj8X6MvyvxfqjfPSlB5y41sduI/Whw4L/bEUCAbEeIzyEAAQhAAAIQgEBvCTRy/Eq6Wldh3VVEj3ZrHUuCWxtVXO1zHUoMiNTbSLJfiSAJD+0vHO2tCetb++Ll6pdvvW0XbBCWpQhixRRjCT4X70cc15R4P0ajKNodVSJ5NaNRxVz7nng/DrrYD8no9Sht8fqGOQKBNQQQIGuA8BYCEIAABCAAAQj0l0CSqVar27PLxUbicqDH6w91HASBOEBk6ZX8JEHoEg5SMGFppL8ZsO4vmYX/6bfffl1ps6StCA/xgOi6iA8T1wLJfBXH9agW1uNyaSK+U6tK5isJCZmQqufHz7fS7rZe+4uO1jNBAAGSiWlkEBCAAAQgAAEIeEXgnLN2Wn6eVGZfqPdWF7QEogfFSHwNSfrdKAgkDkS+1UtwSBi8Y09/a4D8yz8v/5EKgsXQqkVjQ8l+JfU/RlQ5Fk9ItVCvxVqWX1XHovG4bsYXl8y1239r1PS0wfvh5pGtUwIIkE6JcT4EIAABCEAAAhDoEYFWDRBXBcRIDRA7IlmwtBMfzeVX8nr4YNDX+A9XdPCffP7+1601ZZf5ShaDNZdehTUVFOqluBiN7x6LSvtjc1uWXh08/qRRB2+vTLuL96NH90NemkGA5GWmGScEIAABCEAAAqklEI9pvcul4JUo9KQGiMR/GB1KXl4TfvDJUl/jP37rSw+/LOu+ygKnbCTlbqCDaiwVz3XBBZ+P1M2uKHooHo+3xftROtAsOnj8maboIPA8tTdVig1DgKR4cjANAhCAAAQgAIGMEmjVAFHNGiDV+9rcW9LiAGnU/5DlV4EyyRKsI+8M9/eLwg3xfnz2T8rfsYEqaxEfRmI/Gml345qtRfXYxFEc74p2F/ZI6l3xfkiKLNLu9ms28tMuAiQ/c81IIQABCEAAAhBIFYGTamUNkCgIJQVvzXlBJABdKqDLj5YaIEcmC/v6Zfb/+Jm7nxehI0uvpPCgiI+iiquBVDzXEnguWbCiUiGOy8UoCTzfWz1mZq9J1qvlDe/HMgp2OiJQ6OhsToYABCAAAQhAAAIQ6CmBqPK2rL/aLQuulI6NVDyXVytLsKQCodQCjIP9E8GBnnbYbOzb12vf/Pb1aN5VO5fUv+UwlLofRlcDqfuhgli8H8VI26WoJHoonpiyEwdEfBx2aXdXipB+WEabWSeAByTrM8z4IAABCEAAAhBIE4Hl1LutGiBKHZAAdEl25QoQSgosVwMklCAMGzgPSBhOTgQ9X4JVk6KDF159+KVYAs9F70gSYFl+FQcSfB5Uq1J0UFZeRWNRPSrf3x272I+91ct4P9J0F3luCwLE8wnEfAhAAAIQgAAEfCLQXMHUqgEi4eWT41IDpKR1aWRXkoLXuGogEguiXSFCY4KDe3ufgvcr16p/evX75XkJNCknHhAXfC7Lr+phXCtJ5qs4knVX9UbmKxf7cfmwq/mB98OnOy3NtiJA0jw72AYBCEAAAhCAQPYInDsvXpDpZFzvWgx15GqASAFCI1XQ43ojCL2RCUs8IOIQKRZ6W4SwFtnKC6/ef13bYFFCypdUqMqieCpSgqSq4notqFcl+1W1XilE8f0fleOk6OC1aWI/sncnDm1ECJChoadjCEAAAhCAAATySeBsMuzqY8VkOVY8tl/buhQglxRYViSHkeKDLvZD4s/1f/iB0cO9ZvTFP69+af6uvStxJmVRFeUk81VdAs/DqCZlEOsmKkVjhZpkvYpMYSKyo/vkNFfxPIn9WF5B1muzaC9HBBAgOZpshgoBCEAAAhCAQDoITK8wI5YUvKNSAySu1mTxU13EhytC2MiEtX887GkRwgdlc/f87y68rl3mKxs3637oinaB5zVZehXXo1pYjx/Ge82dWtU478flN2X51aNt5f6jo+xBoAMCCJAOYHEqBCAAAQhAAAIQ6AWBB09cTlwJ9T0SfD4qP1EgNUBkGZaIjyCKJf5DSRVCHfzUT5R+vBf9tdr4wtcrX3YpdyWaoxzYgiy9ksrnxtR0IapZFdVHd5WicmH3svfjmhQgbFQ9PyvCA+9HiyOvOyOAANkZP66GAAQgAAEIQAACXRBwNUAKOl66o6X0hzay/MpIBUAj+qPlAZFv/KJMbM++9buig5989f6fJUuvRIS4oHOX9crFfljn9ihJ4HlcjcZK9eW6H+qgxH4sVz0X2cIGgR4QoA5IDyDSBAQgAAEIQAACEGiDwDoxEVVCbfcF2taMxITroCA5eGMrgeiyBEuKgYQ/fnjkvW2029Ypv/Xlh18SBSGeD1WW4POKkcBzETxVpWp1pUuS86oa3Svvjhf3VszeqSkzoURwLNf9oOhgW5A5qS0CeEDawsRJEIAABCAAAQhAYKcEmg6Ea6/olTVAxsUDMiJZsEZcALpUQQ91IwhdfB/B6EhvMmB950b9zc9+ZelfS3X1soyiLGKnIg4XqXgu/peRsBZHcVQbGY/F+WFc2t3RW8qurnq+07FzPQQeEUCAPGLBHgQgAAEIQAACEOgvgSQF7zPSx5PqXftCvbsQSs1xJzzc8isnPqJAVl2JW0R+jC0c2NObGiD/+HMPvqADtSh+jEUJ5VgKxQsSRlFSeFBHhdr4rnpUr9Wj+2E53ls9Zi7fFR8JdT/6ey/kuHUESI4nn6FDAAIQgAAEIDAcAtXH3kqWY8Vj97SRIoQuBa+rAeLqfwSxSUTIoYOFnmTAuvq92reu/lVt3sV+GKsqEukuVc+bma9E/jjvh5G65620uxNu2dWqjeVXq3DwZscEECA7RkgDEIAABCAAAQhAoF0CZ9V0UgX9WHKBhIFLDRCXgjcIClKO0AWgm4KSGiAm+A+Ol4602+pm51XrtvoPf+veF2xgylJgpCKZtSqxDaTmR1CrjdRrJo6i8Xo9ehjHSdrdvdV7Jll6hfdjM6Qc7wEBBEgPINIEBCAAAQhAAAIQ6IRA9GBO18uNFLyuBkixIEuwSuL9cGl4ZfmVuCCCd78z3N9Jmxud+5W/qPzZzbu1u9YFnosIEYEjsR9xtR7GNVuVuh9RUep+PCo6ePnwSen6lRVN4f1YAYPdHhFAgPQIJM1AAAIQgAAEIACBtghMTyenxROu3Mce5eI/Yl0LbFyUCoROfEgGLCmDfmSysK+t9jY5yXk/Xvj9B6+LllmSL3zlJOhcAs+lwkhNxWGtFNUjF/sxOlk3E1J00Hk/1DVZfuXS7lL1fBOqHO4FAQRILyjSBgQgAAEIQAACENiawHIK3ge3LutoX6ERAyIZsGJdFfExqguSAsvFgGiXBcuoYP9EcGDrJrf+9Pe+svjFH74d33WxHy7uQwJMEu+HloRXSkd1U5Kq58VaXFnYE99eXDKNiucrvR9rY0G27o9PIdAuAQRIu6Q4DwIQgAAEIAABCHRN4FEK3qSJG0pFFa3H6w+lAKFkwZL4D5Ok3xUniDVJFqzJiaDrJVj3l8y9F37//p9KX2UpOFiW3t1rVdwtjbS7cT2KZPlV5cFEXByP7eg+OeXgbbwfXc8vF3ZCAAHSCS3OhQAEIAABCEAAAt0SSDSIS8F7UhlJwRuPLyQZsEqSAWvExYC4+A8Vy7os5wUxwZ4x3bUA+T9eW/q/lXg+rJK4D+f9kKVXUuAwCT634v0YjUrRWGF37DJf3Za6HxOHH6wQH8kAm4qp28FyHQQ2J4AA2ZwNn0AAAhCAAAQgAIHeETh/Pll25YoQHpJW91YPuNS7sgRLu1ogQWDi0BUfFAXismGFE7uCrmJA/vpv69//53/08IqydlHFasnV/aiFUTkMgkpdh1UbjtTjsWpUXqjH90qHkrofs9emVwgOAs97N+m0tBGBwkYHOQYBCEAAAhCAAAQg0GsCZ1c1GI+Jn0OUhpIgdCtLsJz2cAHoEnkR/kcnu0/B+5nXlv5YyghK4LlUFRThIXEl1TAsVqqmWi/GKhqJgnikvDs275ByIHvfsBPqSatc7Y8k8HyVibyBQF8I4AHpC1YahQAEIAABCEAAAusJJDVAjj+p6nsCqf1xX5fKZQlA17rgll+NyI+8yrIpCUAPuypC+J0b9e987qtLbxhtKlZ+XO0PLbEfxbqpu8xX8WgtkvofcUUy8LqlV6O3nrRJ3Y9lU/F+LKNgp28E8ID0DS0NQwACEIAABCAAgbUEplX1zlu6FO/VqiZ1QHZZPWJqQaxKskAqDmwQy0opHT75d0YOr72ynff/6HP3/kDiPcTrYcvGxJWwEErgubg+JPNVqTgaFWMTlSQBr6otmsrhY+L9EM8H3o920HJODwngAekhTJqCAAQgAAEIQAACWxKYdp8ekwxYb2vJvKsl8642hZIEoEeBGZE1WG4JlnhAdo/qXVu2s8GHV79X+9a3/6p+ywZKxIepSEBJ2cTiAYmDmizxqruq57XFWvxAAs9vTER29NZlvB8bcORQ/wkgQPrPmB4gAAEIQAACEMg3gdU1QKQKulIHlJGwjziQ2HOJ/yi4AiCxq0PoaoCEwXsOjRzrBJkrOvgPf+veF0S8lJU15dCWynFBsl7JsisdRjVTHIlGl6J4ojARu6KDpQPH7OUk8xWxH51w5tzeEECA9IYjrUAAAhCAAAQgAIFNCDQTTF17RYTHSTlnSk2OB3q8JOl3JeajIBmwXAre0KXglUro8i7cpKFND3/tL6p/cuvt6I6yI4su65UNY/F+6IqU+qhW41otiAo1M1aJqqVq7LwfB2dnper5tBh2vtkmsR+bwuWDnhNAgPQcKQ1CAAIQgAAEIACBNQTOuRS8rgaIUof23dBRVdLvSgpe996l4XXiw4kQlwXL1QE5ciB8j/usna1Wt5VPXrr/FRd0HojwsKpQDoKoosTz4QLPS1EhGo9qUbk0EZfuRnZv9Z6ZTYoOOu/HWREhiRntdMU5EOgJAQRITzDSCAQgAAEIQAACENiegKsBotRRFY/dS4oQugxYNpQfMyIuCIn/kCCQowcKHWXA+uzXyv9y/m58V5REUnTQZb2KTFxzsR9Kig6aUj2qF2rxeFw3txeXzMSbUnQw2c63DG6+b73lFQL9JUAWrP7ypXUIQAACEIAABCAgBM4ql4L39vS0UvduiEQIdEkSXwVSpDzWo+L9cNKjEYT+7/9kqe0MWPeXzMKvv3r/6+JLkXS7oQSf64oJoqoq6Joom1qxVokqthjV9C5z8MGiHd1XtrPq9oqq53g/uD0HTwABMnjm9AgBCEAAAhCAQE4JuBS8teq4aIUJZaK6VoVRyYBVlxogkgArkkKE4rbYOx60nQHrt2cXk8Bz8Z6UJd1uJZDAc1vX4vnYVbNhtS5Jd6OxUimWSBBze2rJHFQnJe2u/DwqOoj3I6f34jCHzRKsYdKnbwhAAAIQgAAE8kPAeT+am3EpeCUCPYn/EP1hIwk9N5ITS5Zh/RtH2qsB8jc/iq//b19c/JbW4kYRz4cUMRTvh3hCwrBWlbofo6YYxWPVqLxwI75z+JCIjycNRQdbM8DrMAkgQIZJn74hAAEIQAACEMg6geU1Tg9uXdbRg4KulwNZdLUYxNWqVEF3K6WUeEFUIKEg2oor48De4EA7UH7ny0t/JFHrZblGfqTmh6t6LrEftUJUK8ZxZKN6VL6/Ox5/x35TuPOWPXhNgs6Pk3a3Hbac018CCJD+8qV1CEAAAhCAAARyTaC5wilJwdsAEU/c0aamdUk8IAUt3g9XA0SyYLkaICIP9OTu7QXIW7eiN37vaw//0rjMV1ZVwiCW5VdBVYp+1JUJa6MSeF4bqcel/bGZTzJfHTOvrJoH0u6uwsGbgRJAgAwUN51BAAIQgAAEIJA7As0UvJW7u/ShfQUd7X6njqUGiImc50NS8Erch7IN74fLhLVnNNi/HaN/9Mq9z8s5iyIjFmOll5wXxJiooqv16qgeqT8MRur12nj09vfrZlxiPyYOr/R+ID6248vn/SVAEHp/+dI6BCAAAQhAAAK5J3B2FYFJWYK1KEEbrtqgLJuSSoQjUqw8Fv+H5LKSR8O7d+ktBchffL/+jatv1eflcqn5IZmvAltRxlU91zXRMXUTR9FodTxWqmKqjx01o7cu29m7IkBekR82CKSAAB6QFEwCJkAAAhCAAAQgkG0CLgWvOv5kMsiouqAlU5W2sgSrUQNEaSviw8V//DtPFLeM/6hFtvyrv7nwWbf0SsRGJVmCFQQVHUswiRQejIuScncpiiuFKP7h3diWDrxhLx+Wuh8u9iPZ8H5k+07zY3QIED/mCSshAAEIQAACEPCcQJKCdzHUat8+NVp0S7C0HhEPiJV1WE58WEmB9RPvLmzp/fjTf119/ead6K4Sz4es36rIJVUXeO4yX6lqvT4W1uujYS0efWdkRh9WxPshTpJr0yI+losOek4R87NAAAGShVlkDBCAAAQgAAEIpJvA9CPz4qoTH2UtDhDJglVPsmAlZQjllOM/NvLuR2eu3nPej0++ev/LkvGqIi1UrASeJ1XPVVANYhEgoj5qS3XxfkzEE3NVU9pds5dd1fMk89VZESF4P1YT5d2wCCBAhkWefiEAAQhAAAIQyDqB5RS8Sk3LWI+p+p5Ax9X7SQ0QN3hbkLgPcYW4fbeNl4Kxxt76//7B1yufu3nH3k1S74r3Q4LPq84DMio1P5SOJPajFJULuxPvx42JKKl6rg5K1XO8H+thcmSoBAhCHyp+OocABCAAAQhAILsEmmEXkoL3wb4f11HtgFYlKXK+d69SCw+UDWpSEb0ow48SBNooe3h/4e9sxGOxYu/8L7+38FUltT7EkSGxH0EliHRFQklqklCrbkYqkazDisd+pOOJB1WjisfM5TdnrZp+pln1fFnjbNQ8xyAwUAJ4QAaKm84gAAEIQAACEMgVgUSDPCNDPqnU1JSKlwK9u/ogCUA3hVIShK6UPA/WSsqBWDNaNKJQ1m+f/ZPFfyHiY0nOW7KqUA6l8GAYiBdEAtCrI4WaCJl6NDJav/+ed8W3F6fM5bty9vS0Uedc8Hmy9Kqphta3zREIDJoAAmTQxOkPAhCAAAQgAIH8EDh/ftn1EN27kexLyHjy6qqgq1pNWLiCIK4SSGwP7i38m2vh/PBe9Jef+oMHX3dZryRZViWIY1l+FVTrEnheknofseTdjeNqVJqPGxXPj4v4oOL5Woy8TxEBBEiKJgNTIAABCEAAAhDIJoHK3TcS0RHtfjt5NRKBnoy0KEuwgoKNjbXGBFK7Y/32ua8tfU7KhlRc1ivjYj9GdFUVYhEfRuI+4mgs2hWV7++O335H3ZR+cMzOXmul3HVtEXi+nihHhk2AGJBhzwD9QwACEIAABCCQIwKuzEdVagTKi0gQHdes+CuknqAyZ/6TyZ9YC+LmnfjP//kXH3zLeT+sLlRCG1WtsTVli7VyVK8HJowCE0Wl/eIHqR41B533Q2LbG0uv1rbGewikgwAekHTMA1ZAAAIQgAAEIJBJAmc3HFUQSjJd9xNZKf9RMIEKzeSEXhf/8cnP3f/fnfjQrt6Hiqsu85WOg5oK4npJig7Gu3ZFrujg27HzfryB92ND2hxMGwEESNpmBHsgAAEIQAACEMgWAVcFfYMtiEq2Ho7YuCCrr2Ibv+fwyOMrT/v+30Zfev0vqjdMUKiIQpG4j1jS7gZVV3TQ6hFZfhVF1SiKkqKDUcVc2ydFB4n9WImQ/ZQSQICkdGIwCwIQgAAEIACBLBK4oySlrtV1a+u2bAraxmFkYxuG0VhRL9cAiWK1+KsX7/1TKZJe0ZEIj0iKDYr3ox7HiffDBZ5HUS0qxbG5ow6Z0gFZynX4pGS6Ot+ERuxHFu+erIyJGJCszCTjgAAEIAABCEAg9QQKD/dbtaeqAhEgVpVsIM4PE4SxhKBH+yeC97QG8N2b9c++8Tf1t0MJ+ogCXbNSbDBwS69C+dFhPaqXouj+/Xjv+Iip3nnLXquK9+OuxH68klQ8bzXDKwRSSQAPSCqnBaMgAAEIQAACEMgMgYPTK2pw3FZBRaLIzagZCSWHleTUNaYSFcWzsaukH3NjrtXs/CdfefDbrtaHqBSp9xFUwmC0EsmrjlzNj3p9byA/4+PRnVrV7K0eM+ru9yT17vlWP63XzCBkINkigAckW/PJaCAAAQhAAAIQSCGB0X1P2sW7czZ8xwE7EhZNtVK3dXF+2MjEpWJBQtFDXSzoQ870b/91/Tf+1fXqnWCkIGe4MulBXWqFiOdDan6I40NLzY96KYjfLsR2710pOjgnng8qnqdw1jFpMwIIkM3IcBwCEIAABCAAAQj0jMBlVZg4aUd2z9vCHfFrVGOp+VEKgt21urIF9Z8/PXbEdRVF9tZ/9am7nysVtaTVjYzU+xCJ4ioVRhL+EUSxkdVX5Wq8u1Cyo6WjZvTvifjYJz9/X34aW+u1+ZYXCKSPAEuw0jcnWAQBCEAAAhCAQGYINILCJ5IA8bdU8V5sHx6ITS0ci+uy/Kq2JE4OCSj/u+8N3+WG/LW/rP43oQ0l2Dys6TCqafcqy66Mq3iua/VafSzaXdgTu6VXLu3u5d8V4fFGS3wQeJ6Z2ybjA0GAZHyCGR4EIAABCEAAAkMkcE6Cwl1qXNlKP6jZ0t2jNnxobFEiP0bDKJb1V5JLN44ndxXGKjX7Z//1/3r3qzUJOA91VK2r8apbdmV3R/VI/j8u4mOX1Pz44d3Yji9OmWu3/9aog9L2uZYAGeI46RoCHRBAgHQAi1MhAAEIQAACEIBANwRmrynr4kBuTCg7LkUDH8piqpo4NcZEWFg1Uv/RvXjuzRv1X0sEh4rq7tUE7lWWXt114qOaFBy8V6rGow8rZtQtuzp4W8RNK/Ac70c388I1wyGwYWGc4ZhCrxCAAAQgAAEIQCBrBKwWD4VW15SePq707WtvBIvjY8GBYimoFArB6MSDsHa/IKEggY5HtZZ1WTocMTaUWiEPi+Ip2ROZh3aP2b1QTzwfo49VzNEDx2InaB4VHUy+zhH7kbVbJ8PjQYBkeHIZGgQgAAEIQAACwyYgAsRtTRFyct/l4F5pb1D5wWjw7qNKLYYjwUQQBlF5QRZdHVj+XiYx5nZh0djS/tiM3DfWxXwUJiLrUu5evqsk5e7KpVd4P4Y9y/TfGQGWYHXGi7MhAAEIQAACEIBABwSWNYVc84q6/OaDREQ4T8b83ShZjlUR70a5NBHXy7Wovkd+5DWqVqP9eyvR/h+V43ulQ7GL+dhbvWcuH17p+XBmID46mAxOTQmBlf8qUmISZkAAAhCAAAQgAIEsEVjtBVG3Z/XJJyZ05e4uXX2sqKMHBT01pVT13pR8L7uhSnuP2rm5OUnbO2VLByR25JayEyI8Hi27Oi9wliues/QqS7dKTsaCAMnJRDNMCEAAAhCAAASGSWClCHlFq9sH9fT0tHpwS4kQeUOr40+q6p23ku9lpQPHRFS8oUZvPdkQHs7sVTEf7kByKuLDoWDzjgACxLspw2AIQAACEIAABDwkIN+5mnrBxYO4TQLTnTfECRG3Pbh1OTneqBkyq2avTTcuaKbxfZRuNzkN8ZFQ4z8+Emj8A/DRcmyGAAQgAAEIQAAC3hFoekLUecmOdbZh/TXxiKhn1ozkFaWOP9MQGavqfBDzsQYUbz0kgADxcNIwGQIQgAAEIAABnwm0REhzDOdEjCRbU5C4/VWio/EpAectDrz6TgAB4vsMYj8EIAABCEAAAp4SWCNENh0FXo9N0fABBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhDoI4H/H9ZM4sWVD4JuAAAAAElFTkSuQmCC", "created": 1774109179865, "lastRetrieved": 1774109179865 } } }